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 45525

Article: 45525
Subject: Re: Is the WebPack Constraints Editor evil?
From: Troy Schultz <tschultz@canada.com>
Date: Thu, 25 Jul 2002 15:10:50 GMT
Links: << >>  << T >>  << A >>
I too was recently a newbie to the Xilinx Webpack software, but found it 
to be a fiarly good piece of software.

The problem you are having with the constraint editor, I believe is due 
to the changes you have made to your design not being saved.  Make sure 
you save any design/code chages before entering the constraint editor.

Also if you have removed pins from the design/code you will have to 
manually edit the constraint file to remove them.  Normally one would do 
most of thier design and allow the software to do as it pleases, then 
lock the design, then use the constraint editor.

Once you have used the constraint editor, keep in mind that you are 
essentially working with a locked design, and may have to manually edit 
changes.

Hope this helps and doesn't confuse things too much.
- Troy


Børge Strand wrote:
> Is it just me, or can the WebPack icon "Edit Implementation Constraints
> (Constraints Editor)" be a little touchy?
> 
> I'm really a novice when it comes to FPGA programming, so having somewhere
> to point and click is a nice start. But when I add new signals (which I want
> to map to pins) to my source code, they don't appear in the list in the
> Constraints Editor. Initially, in a brand new project, it finds several
> signals and lets me assign pins to them. But as I keep working, making the
> Constraints Editor find, and not least save, my signals gets increasingly
> difficult.
> 
> When I add a signal/pin in my source code, and the Constraints Editor fails
> to see it, I rather edit the ucf file. If I hit the Constraints Editor again
> after updating the ucf, the constraints editor refuses to start, stating
> that my newly added signal does not exist.
> 
> I'm all ears if you have any suggestion regarding what I should do about the
> Constraints Editor. I'd like to use it if I could only find it trustworthy.
> But the best thing would be to put the constraints into my verilog code. I
> mean, your modules could go with a verilog testbench for simulation and a
> verilog constraints file for implementation.
> 
> 
> Regards,
> 
> Børge
> 
> 
> The error message and code are inserted below.
> 
> ERROR:NgdBuild:397 - Could not find NET 'resetl' in design 'implementation'.
>    NET entry is 'NET "resetl" LOC = "D8";
>    '
> ERROR:Parsers:11 - Encountered unrecognized constraint while parsing.
> ERROR:NgdBuild:19 - Errors found while parsing constraint file
>    "implementation.ucf".
> 
> 
> while the top of my code reads
> 
> 
> module implementation (clk_100, resetl, button, segment2, segment1, led,
> countednumber);
>  input clk_100;
>  input resetl;
>  input button;
>  output [6:0] segment2, segment1; // two seven-segment displays
>  output led;
> 
>  output [2:0] countednumber;
> 
>  show dice (clk_100, resetl, countednumber, segment1, segment2);  // shows
> selectednumber as dice eyes
>  numbergenerator counter (clk_100, resetl, countednumber, button, led); //
> count while button is pressed
> 
> endmodule
> 
> 
> The "resetl" signal was added after I had been working on the code for a
> while. And if you wonder, the code implements an electronic dice.
> numbergenerator counts on clk_100 as long as I keep button pressed. show
> continuously translates the generated number into dice eyes.
> 
> 
> 
> 



Article: 45526
Subject: Specifying memory during synthesis
From: "Ryan" <ryans@cat.co.za>
Date: Thu, 25 Jul 2002 17:13:37 +0200
Links: << >>  << T >>  << A >>
Hi

I am synthesising a memory management system using LeonardoSpectrum (level
1 - web edition) and the code is written in VHDL. What I am trying to do is
shift data into an array as it is received. Currently the array is 32 bits
in length. The problem is that the length of the data that I add to the
array varies, and what I find is the shifting (left) concept when dealing
with variable bit lengths requires far too many logic elements. As far as
the synthesis is concerned, currently the entire piece of code is placed in
logic cells. This is too expensive! Is there a way to define the array as
memory rather than logic cells or is there another method of combining new
and old (variable length) data together besides shifting and then combining
within an array?

Any assistance would be greatly appreciated.
Thanks
Ryan





Article: 45527
Subject: Re: hold time
From: John_H <johnhandwork@mail.com>
Date: Thu, 25 Jul 2002 15:23:41 GMT
Links: << >>  << T >>  << A >>
Registering inputs or having the logic fed by the inputs close to those
IOBs would help reduce the hold time.  The spread between worst setup and
worst hold is due to the different propagation times for the input logic.
If you can get the inputs registered in the IOBs, you will have no hold
times and still very good setups.  If you can't afford the "extra" clock
cycle, manual placement of the logic can help out.


Anjan wrote:

> I am interfacing a DSP to xilinx fpga. The DSP writes to a fifo in the
> fpga. The timing report gives very good setup time but large hold
> time. The DSP doesn't introduce hold time but can have wait states.
> Can any one suggest a way in which I can reduce the hold time
> requirement.
> Anjan


Article: 45528
Subject: More: How to implement efficient wide word comparator?
From: John_H <johnhandwork@mail.com>
Date: Thu, 25 Jul 2002 15:35:29 GMT
Links: << >>  << T >>  << A >>
As Giuseppe's suggestion sat around my brain for a while, I got to like the
hybrid approach more and more.  In telecom (SDH), often I needed gating for
various bytes in the frame overhead.  I had several lines in the frame and
bytes of interest at the front of each line.

If a different line "strobe" was used for the start of each line in the
frame (generated from a counter), the strobe could be passed through
different SRL16 elements with delays programmed from one to 16 (or 2 to 17
if you include the nice little output register attached to the SRL16
element) allowing multiple strobes coming at precisely the right time based
on the row strobe event.  Ideally there's two counters in the SDH framing
system: a column count and a row count.  The column count is a byte-by-byte
tracking of the input data with a modulus that's the length of the row;
when the column counter resets the row counter increments.  The strobe from
the row count - when it increments - feeds the strobe chain to give the
gating to the correct bytes.

No magnitude comparators needed.

None.


Article: 45529
Subject: Re: LVDS interface cable recommendation sought
From: John_H <johnhandwork@mail.com>
Date: Thu, 25 Jul 2002 15:43:40 GMT
Links: << >>  << T >>  << A >>
Triax is a shielded, twisted pair.  Quadrax has two shields around the
pair.

Even coaxial cables leak.  Otherwise any coax with the same dielectric
would do.  There's hundreds of types of RG59 available.

The theoretical model of a coaxial transmission line has no external
crosstalk - everything balances out.  A critical spec for "coax ribbon
cables" is the propagation delay match between signals.  A differential
signal taking two different routes won't switch with the same kind of
symmetry.

While the twisted pairs won't emit much energy because of the differential
nature, they are susceptible to common mode coupling from outside sources.
But the LVDS receivers are built to reject the common mode and only look at
the differential.

Coax reduces crosstalk and emissions.  Differential tranceivers reduce the
effects of crosstalk and reduce emissions.  Differential transceivers
guarantee matched propagation delays, coax doesn't.



JP Nicholls wrote:

> > > > More important, coax cables reject external fields a whole
> > > > lot better than twisted pair,
> > >
> > > How come?  Unless the co-ax shielding is ferromagnetic,
> > > surely a co-axial pair will present a greater area to any
> > > local magnetic fields => induced currents.  This area will
> > > be hugely reduced with a twisted pair.
> >
> > It is the symmetry - in a coaxial cable the outer conductor is
> > perfectly symmetrically arranged around the inner conductor, so they
> > both see exactly the same magnetic field, and the pickup is zero
> > over-all. Do the math.
>
> I agree with this completely for a *single-ended* signal,
> but what about *differential* signalling?  Your original
> reply was:
>
> > More important, coax cables reject external fields a whole lot better
> > than twisted pair, and routing a differential pair of signals along
> > physically coupled pair of coax cables will do a better job than
> > routing the same signal along a shielded twisted pair. At a much
> > higher price ....
>
> I'm assuming that you mean that the co-axial *pair* is
> arranged so that the two polarities of the differential
> signal are travelling side-by-side in physically separated,
> shielded cables.  Maybe I'm missing something, but I can't
> see how this presents less loop area to an external field?
>
> Thanks for you interest and help.


Article: 45530
Subject: Re: hold time
From: Ray Andraka <ray@andraka.com>
Date: Thu, 25 Jul 2002 15:59:23 GMT
Links: << >>  << T >>  << A >>
Nope,  long delays on the data inputs will increase the set-up time.  He has
a long delay on the clock path.  Use the DLL to reduce the clock distribution
delay.

John_H wrote:

> Registering inputs or having the logic fed by the inputs close to those
> IOBs would help reduce the hold time.  The spread between worst setup and
> worst hold is due to the different propagation times for the input logic.
> If you can get the inputs registered in the IOBs, you will have no hold
> times and still very good setups.  If you can't afford the "extra" clock
> cycle, manual placement of the logic can help out.
>
> Anjan wrote:
>
> > I am interfacing a DSP to xilinx fpga. The DSP writes to a fifo in the
> > fpga. The timing report gives very good setup time but large hold
> > time. The DSP doesn't introduce hold time but can have wait states.
> > Can any one suggest a way in which I can reduce the hold time
> > requirement.
> > Anjan

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 45531
Subject: Re: Is the WebPack Constraints Editor evil?
From: "Børge Strand" <borge.strand.remove.if.not.spamming@sintef.no>
Date: Thu, 25 Jul 2002 18:00:05 +0200
Links: << >>  << T >>  << A >>
Thanks Troy,

I'm a lot less confused now, at least when it comes to the pinout. I played
with wait's and @'s the other day, and the Constraints Editor had strong
opinions on those as well. I'll look more deeply into those tomorrow morning
and post again if there are still problems.

--
Børge

"Troy Schultz" <tschultz@canada.com> wrote in message
news:3D401458.9090904@canada.com...
> I too was recently a newbie to the Xilinx Webpack software, but found it
> to be a fiarly good piece of software.
>
> The problem you are having with the constraint editor, I believe is due
> to the changes you have made to your design not being saved.  Make sure
> you save any design/code chages before entering the constraint editor.
>
> Also if you have removed pins from the design/code you will have to
> manually edit the constraint file to remove them.  Normally one would do
> most of thier design and allow the software to do as it pleases, then
> lock the design, then use the constraint editor.
>
> Once you have used the constraint editor, keep in mind that you are
> essentially working with a locked design, and may have to manually edit
> changes.
>
> Hope this helps and doesn't confuse things too much.
> - Troy
>
>
> Børge Strand wrote:
> > Is it just me, or can the WebPack icon "Edit Implementation Constraints
> > (Constraints Editor)" be a little touchy?
> >
> > I'm really a novice when it comes to FPGA programming, so having
somewhere
> > to point and click is a nice start. But when I add new signals (which I
want
> > to map to pins) to my source code, they don't appear in the list in the
> > Constraints Editor. Initially, in a brand new project, it finds several
> > signals and lets me assign pins to them. But as I keep working, making
the
> > Constraints Editor find, and not least save, my signals gets
increasingly
> > difficult.
> >
> > When I add a signal/pin in my source code, and the Constraints Editor
fails
> > to see it, I rather edit the ucf file. If I hit the Constraints Editor
again
> > after updating the ucf, the constraints editor refuses to start, stating
> > that my newly added signal does not exist.
> >
> > I'm all ears if you have any suggestion regarding what I should do about
the
> > Constraints Editor. I'd like to use it if I could only find it
trustworthy.
> > But the best thing would be to put the constraints into my verilog code.
I
> > mean, your modules could go with a verilog testbench for simulation and
a
> > verilog constraints file for implementation.
> >
> >
> > Regards,
> >
> > Børge
> >
> >
> > The error message and code are inserted below.
> >
> > ERROR:NgdBuild:397 - Could not find NET 'resetl' in design
'implementation'.
> >    NET entry is 'NET "resetl" LOC = "D8";
> >    '
> > ERROR:Parsers:11 - Encountered unrecognized constraint while parsing.
> > ERROR:NgdBuild:19 - Errors found while parsing constraint file
> >    "implementation.ucf".
> >
> >
> > while the top of my code reads
> >
> >
> > module implementation (clk_100, resetl, button, segment2, segment1, led,
> > countednumber);
> >  input clk_100;
> >  input resetl;
> >  input button;
> >  output [6:0] segment2, segment1; // two seven-segment displays
> >  output led;
> >
> >  output [2:0] countednumber;
> >
> >  show dice (clk_100, resetl, countednumber, segment1, segment2);  //
shows
> > selectednumber as dice eyes
> >  numbergenerator counter (clk_100, resetl, countednumber, button, led);
//
> > count while button is pressed
> >
> > endmodule
> >
> >
> > The "resetl" signal was added after I had been working on the code for a
> > while. And if you wonder, the code implements an electronic dice.
> > numbergenerator counts on clk_100 as long as I keep button pressed. show
> > continuously translates the generated number into dice eyes.
> >
> >
> >
> >
>
>



Article: 45532
Subject: Problem with mapping
From: "BROTO Laurent" <lbroto@free.fr>
Date: Thu, 25 Jul 2002 18:26:05 +0200
Links: << >>  << T >>  << A >>
Hi!
I've succed to synthetize opencore PCI IP Core and now I try to do a top
with this core and another one.
I can synthetize without problem but when webpack try to map this top, I get
the following error:

ERROR:Pack:1107 - Unable to combine the following symbols into a single IOB
   component:
    PAD symbol "CLK" (Pad Signal = CLK)
    BUF symbol "CLK_IBUF" (Output Signal = CLK_IBUF)
   Each of the following constraints specifies an illegal physical site for
a
   component of type IOB:
    Symbol "CLK" (LOC=C11)
   Please correct the constraints accordingly.
Problem encountered during the packing phase.

I would like to know how can I solve this problem.

Thanks,

BROTO Laurent




Article: 45533
Subject: ALU in VHDL and a bunch of questions
From: dmitrik@mailandnews.com (Dmitri Katchalov)
Date: 25 Jul 2002 09:34:33 -0700
Links: << >>  << T >>  << A >>
Hi,

I'm new to FPGA. I'm trying to replicate PIC16Fxxx core as an exersize
(any real programmer should write at least one OS and compiler :)

I'm trying to synthesize a simple ALU. I'm using VHDL and XST (WebPack).
Target is SpartanIIE. It sortof works but is rather inefficient. 
At first I tried a big case statement for all ALU operations. 
XST happily infers lots of built-in macros (one for each ALU op) 
and a huge output mux. For example it produces 6 carry-chain adders 
(one for each ADD, SUB, INC, DEC and another two to get the 
half-carry bit for ADD/SUB) where I would think one is enough.

I've narrowed the problem down to a simple adder/subtractor:

   if add='1' then 
         Y <= A + B; 
   else 
         Y <= A - B; 
   end if;

This works fine, produces a single 8-bit adder/subtractor. 4 slices in total.
But this does not give me carry/borrow bit.

   if add='1' then 
         Y <= ('0' & A) + ('0' & B); 
   else 
         Y <= ('0' & A) - ('0' & B); 
   end if;

produces 8bit adder with carry-out, a separate 9bit subtractor and 
a 9bit 2x1 mux. 9 slices. I tried different variations of the above 
with the same results. 

Finally I have come up with the following code.
It uses the fact that A-B = A +(-B) = A + ((not B) + 1). 

  variable tmp: integer;
  variable cin: std_logic;

  if op = '1' then
      tmp := conv_integer(B);
      cin := '0';
  else
      tmp := conv_integer(not B);
      cin := '1';
  end if;

  Y <= conv_std_logic_vector(conv_integer(A) + tmp + conv_integer(cin),9);

This infers 1 "9bit adder carry in" and 8 2x1 muxes and takes only 4 slices.
Much better. One small detail: if I declare cin as integer instead 
of converting it from std_logic at the last step, I'm back to 9 slices. 

Now the questions.

* Am I on the right track?

* I'm trying to describe purely combinatorial logic here. The output 
is supposed to be the same fixed boolean function of inputs no matter 
how it is described. Why such big variations (more than 2 times the area)? 
Is this a problem with the tool or they all like that?

* Should I be tweaking XST settings instead? Is there a magic setting 
like "Do what I mean not what I say" :)

* Xilinx lib has "8bit adder carry out" but it doesn't seem to have
"8bit subtractor borrow out". Is this right?

* How do I get the half-carry bit out of the 8bit adder? I guess I can 
instantiate/infer two separate 4bit adders. Is there a better way?

* What's the story with IEEE.std_logic.SIGNED vs .UNSIGNED? I heard that 
they are are mutually exclusive and math operations produce different 
results depending on which one is in use. Webpack automatically inserts
IEEE.STD_LOGIC_UNSIGNED.ALL at the beginning of every VHDL source it 
creates. Should I always use UNSIGNED?

* Is there a decent on-line reference for all those IEEE.* libraries?
I've found several good VHDL tutorials but none of them covers 
std_logic in details.

Thanks,
Dmitri

Article: 45534
Subject: Re: hold time
From: John_H <johnhandwork@mail.com>
Date: Thu, 25 Jul 2002 17:03:29 GMT
Links: << >>  << T >>  << A >>
Dagnabbit, thanks Ray.

The hold time issues I was getting in my design were due to logic driven directly
by the inputs (as opposed to IOB registers) that was *too* close to the IOBs.  If
the logic has to be fed live as opposed to by IOB input registers, LOCs can be
used to set the logic elements *further* inside the device.  Hold times will be
reduced, then eliminated as the logic has longer routes.  The different input
paths have different setup/hold times associated with each.  Only the shortest
delays need to be adjusted - the longest delays (and tsu values) are already
giving you the worst setup numbers but zero hold values.  You can strike a
balance to get the hold violations delayed enough for zero hold time but not
worsen the setup.

My apologies for the misinformation.


Ray Andraka wrote:

> Nope,  long delays on the data inputs will increase the set-up time.  He has
> a long delay on the clock path.  Use the DLL to reduce the clock distribution
> delay.


Article: 45535
Subject: Re: RLOC Origin problems in ISE4.2sp3?
From: Bret Wade <bret.wade@xilinx.com>
Date: Thu, 25 Jul 2002 11:17:28 -0600
Links: << >>  << T >>  << A >>
 

Ray Andraka wrote:
>I tried the RLOC origin on a smaller macro in the design, and it works fine
>in that case.  The failing macro has tiles which come from a different edif
>netlist.  It is a fairly large macro as well (24x80 slices). The size
>and/or the fact that its netlist comes from nested edif files may be
>contributing factors.  The odd thing is that the RLOC_ORIGIN is recognized
>in the editable view of the floorplanner (which pulls it's info from the ucf
>and ngd files), but is being ignored in place and route.
>

Hello Ray,

I've taken a look at your design and have found two factors contributing
to the vanishing RLOC_ORIGIN constraint:

1. Your macro specification is using the default H_SET set grouping.
It turns out that the RLOC_ORIGIN is itself used to define sets and because
you are applying it to a FF at the bottom of the hierarchy, that FF is
being broken out into a separate single component macro, which I assume
is not your intention. The solution which has been communicated to you
by the hotline, is to move the RLOC_ORIGIN constraint to the hierarchy
level that is the start of your H_SET. Another solution would be to apply
HU_SET constraints to all of the instances you do want in the macro rather
that relying on the implied H_SET grouping.

From the constraints guide:

All design elements with RLOC constraints at a single node of the
design hierarchy are considered to be in the same H_SET set unless they
are tagged with another type of set constraint such as RLOC_ORIGIN or RLOC_RANGE.
If you explicitly tag any element with an RLOC_ORIGIN, RLOC_RANGE, U_SET,
or HU_SET constraint, it is removed from an H_SET set. Most designs contain
only H_SET constraints, since they are the underlying mechanism for relationally
placed macros. The RLOC_ORIGIN or RLOC_RANGE constraints are discussed
further in the "Fixing Members of a Set at Exact Die Locations" section.</i>

2. There is a known problem in 4.2i where RLOC_ORIGIN constraints on
single component RPMs are dropped. This problem is described in
  http://www.support.xilinx.com/techdocs/12192.htm
This explains why the RLOC_ORIGIN constraint did not
result in a corresponding MACRO LOCATE constraint in the PCF file. This
problem has been fixed in version 5.1i. I have confirmed that using your
design

Regards,
Bret Wade
Xilinx Product Applications


Article: 45536
Subject: Re: ALU in VHDL and a bunch of questions
From: Goran Bilski <goran.bilski@xilinx.com>
Date: Thu, 25 Jul 2002 10:58:43 -0700
Links: << >>  << T >>  << A >>
Hi Dimitri,

Believe me, I have been there and I couldn't find a nice way to do what I=
 wanted.

Which was a add/sub with carry-in and carry-out.
I spend a day trying all sorts of way to express that but only ended up w=
ith half
solutions.
Then I just instanciated LUT, MUXCY and XORCY using a generate loop.
That took me 5 min to code which it's way faster than trying to foul the =
tools.

I have found out that if I have to go around the synthesize tool by chang=
ing my
code,
it's way faster to just instanciated what I want.
That also gives me the possibility to RLOC the components and do even mor=
e stuff
using the MULT_AND
and set/reset on the DFFs.

G=F6ran

Dmitri Katchalov wrote:

> Hi,
>
> I'm new to FPGA. I'm trying to replicate PIC16Fxxx core as an exersize
> (any real programmer should write at least one OS and compiler :)
>
> I'm trying to synthesize a simple ALU. I'm using VHDL and XST (WebPack)=
=2E
> Target is SpartanIIE. It sortof works but is rather inefficient.
> At first I tried a big case statement for all ALU operations.
> XST happily infers lots of built-in macros (one for each ALU op)
> and a huge output mux. For example it produces 6 carry-chain adders
> (one for each ADD, SUB, INC, DEC and another two to get the
> half-carry bit for ADD/SUB) where I would think one is enough.
>
> I've narrowed the problem down to a simple adder/subtractor:
>
>    if add=3D'1' then
>          Y <=3D A + B;
>    else
>          Y <=3D A - B;
>    end if;
>
> This works fine, produces a single 8-bit adder/subtractor. 4 slices in =
total.
> But this does not give me carry/borrow bit.
>
>    if add=3D'1' then
>          Y <=3D ('0' & A) + ('0' & B);
>    else
>          Y <=3D ('0' & A) - ('0' & B);
>    end if;
>
> produces 8bit adder with carry-out, a separate 9bit subtractor and
> a 9bit 2x1 mux. 9 slices. I tried different variations of the above
> with the same results.
>
> Finally I have come up with the following code.
> It uses the fact that A-B =3D A +(-B) =3D A + ((not B) + 1).
>
>   variable tmp: integer;
>   variable cin: std_logic;
>
>   if op =3D '1' then
>       tmp :=3D conv_integer(B);
>       cin :=3D '0';
>   else
>       tmp :=3D conv_integer(not B);
>       cin :=3D '1';
>   end if;
>
>   Y <=3D conv_std_logic_vector(conv_integer(A) + tmp + conv_integer(cin=
),9);
>
> This infers 1 "9bit adder carry in" and 8 2x1 muxes and takes only 4 sl=
ices.
> Much better. One small detail: if I declare cin as integer instead
> of converting it from std_logic at the last step, I'm back to 9 slices.=

>
> Now the questions.
>
> * Am I on the right track?
>
> * I'm trying to describe purely combinatorial logic here. The output
> is supposed to be the same fixed boolean function of inputs no matter
> how it is described. Why such big variations (more than 2 times the are=
a)?
> Is this a problem with the tool or they all like that?
>
> * Should I be tweaking XST settings instead? Is there a magic setting
> like "Do what I mean not what I say" :)
>
> * Xilinx lib has "8bit adder carry out" but it doesn't seem to have
> "8bit subtractor borrow out". Is this right?
>
> * How do I get the half-carry bit out of the 8bit adder? I guess I can
> instantiate/infer two separate 4bit adders. Is there a better way?
>
> * What's the story with IEEE.std_logic.SIGNED vs .UNSIGNED? I heard tha=
t
> they are are mutually exclusive and math operations produce different
> results depending on which one is in use. Webpack automatically inserts=

> IEEE.STD_LOGIC_UNSIGNED.ALL at the beginning of every VHDL source it
> creates. Should I always use UNSIGNED?
>
> * Is there a decent on-line reference for all those IEEE.* libraries?
> I've found several good VHDL tutorials but none of them covers
> std_logic in details.
>
> Thanks,
> Dmitri


Article: 45537
Subject: Re: Is the WebPack Constraints Editor evil?
From: "Speedy Zero Two" <david@manorsway.NOSPAMPLEASE.freeserve.co.uk>
Date: Thu, 25 Jul 2002 18:59:23 +0100
Links: << >>  << T >>  << A >>
Hi Børge,

The constraints editor only works on synthesised logic so if you break your
design It will complain.

Ever time you change a file, webpack will recompile the code first.
The errors are because you broke your code and not coming from the
Constraints editor.

Hope this makes sense,
Dave

"Børge Strand" <borge.strand.remove.if.not.spamming@sintef.no> wrote in
message news:1027612806.9313@halvan.trd.sintef.no...
> Thanks Troy,
>
> I'm a lot less confused now, at least when it comes to the pinout. I
played
> with wait's and @'s the other day, and the Constraints Editor had strong
> opinions on those as well. I'll look more deeply into those tomorrow
morning
> and post again if there are still problems.
>
> --
> Børge

snip



Article: 45538
Subject: Re: Wind River Diab Xilinx Edition
From: big_kap@yahoo.com (Kaplan)
Date: 25 Jul 2002 13:08:23 -0700
Links: << >>  << T >>  << A >>
Winnie Hsu <Winnie.Hsu@xilinx.com> wrote in message news:<3D3F41EB.22A2CDB0@xilinx.com>...
> Diab C/C++ compiler  is the tool for embedded applications
> targeting to the PowerPC inside Virtex-II Pro. After the
> compilation,  the embedded system dev tool chain can initialize
> the program memory or load the program memory with the
> executables, then PPC can execute the program.
> 
> It is not a 'synthesis' tool that manipulate C/C++ into the fabric.

Is there a plan to build a 'synthesis' tool that transforms algorithms
written in C/C++ into FPGA fabric?

Article: 45539
Subject: Re: Wind River Diab Xilinx Edition
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 25 Jul 2002 14:32:10 -0700
Links: << >>  << T >>  << A >>
 http://www.xilinx.com/prs_rls/01118celoxicainvest.html

Austin

Kaplan wrote:

> Winnie Hsu <Winnie.Hsu@xilinx.com> wrote in message news:<3D3F41EB.22A2CDB0@xilinx.com>...
> > Diab C/C++ compiler  is the tool for embedded applications
> > targeting to the PowerPC inside Virtex-II Pro. After the
> > compilation,  the embedded system dev tool chain can initialize
> > the program memory or load the program memory with the
> > executables, then PPC can execute the program.
> >
> > It is not a 'synthesis' tool that manipulate C/C++ into the fabric.
>
> Is there a plan to build a 'synthesis' tool that transforms algorithms
> written in C/C++ into FPGA fabric?


Article: 45540
Subject: Re: LVDS interface cable recommendation sought
From: bill.sloman@ieee.org (Bill Sloman)
Date: 25 Jul 2002 16:00:27 -0700
Links: << >>  << T >>  << A >>
jpnicholls@pwav.com (JP Nicholls) wrote in message news:<d61fddc5.0207250438.1f3837dc@posting.google.com>...
> > > > More important, coax cables reject external fields a whole
> > > > lot better than twisted pair,
> > >
> > > How come?  Unless the co-ax shielding is ferromagnetic,
> > > surely a co-axial pair will present a greater area to any
> > > local magnetic fields => induced currents.  This area will
> > > be hugely reduced with a twisted pair.
> > 
> > It is the symmetry - in a coaxial cable the outer conductor is
> > perfectly symmetrically arranged around the inner conductor, so they
> > both see exactly the same magnetic field, and the pickup is zero
> > over-all. Do the math. 
> 
> I agree with this completely for a *single-ended* signal, 
> but what about *differential* signalling?  Your original 
> reply was:
> 
> > More important, coax cables reject external fields a whole lot better
> > than twisted pair, and routing a differential pair of signals along
> > physically coupled pair of coax cables will do a better job than
> > routing the same signal along a shielded twisted pair. At a much
> > higher price ....
> 
> I'm assuming that you mean that the co-axial *pair* is 
> arranged so that the two polarities of the differential 
> signal are travelling side-by-side in physically separated, 
> shielded cables.  Maybe I'm missing something, but I can't 
> see how this presents less loop area to an external field?

I cringe to agree that you are right, as far as magnetic field
interference goes, but there is a complicating factor.

If your pair of coaxial cables are grounded at both ends, the
shielding presents a "shorted turn" to the magnetic field threading
the loop, which reduces the voltage around the loop to the extent that
the circulating current cancels the magnetic field. This gets less and
less effective as the loop gets longer and the resistance around the
loop increases.

I seem to remember that the impedance of free space - that is of a
loop aerial - is about 300R, so I imagine that the loop has to get
fairly long before this shielding becomes ineffective.

In my specific application, we were being pretty paranoid, and our
balanced pair of coaxial links were originally specified as semi-rigid
coax - RG405 - where the screen is a solid copper tube on solid
Teflon/PTFE dielectric. We had them assembled by a specialist firm -
Quadrant Connectors in the U.K. - who told us that Alcatel Quickform
86, where the screen is tin-soaked copper braid, is somewhat cheaper
(if still pretty expensive) and a lot easier to handle and to solder
to the relevant coax connectors.

One of the advantages of these cables is that they offer 100%
electrostatic screening (as well as very good high frequency
properties).

Another would be that you could solder pairs of cables together along
their full length, shortening up the inductive screening loops to an
effective diameter of 2.2mm.

We didn't think about this at the time, and certainly didn't solder
individual pairs together.

One of the nice things about posting here is that every now and again
you get to realise what you should have done in the past, which may
just mean that you can solve a problem before it conmes up the next
time you tackle a similar project.

Thanks for getting me to think about the subject in more detail. 

With any luck Win Hill will chime in with a reference to a paper
published in 1953 that analysed the problem properly ...

----
Bill Sloman, Nijmegen

Article: 45541
Subject: logic elements v/s logic cells
From: prashantj@usa.net (Prashant)
Date: 25 Jul 2002 16:23:53 -0700
Links: << >>  << T >>  << A >>
Hi,
I have the LE count of a design in Altera's Apex20KE1500E device. I
need to know what Xilinx device will this design fit in. Is there a
relationship between the logic elements of Altera and logic cells of
Xilinx ? How can one decide which exact Xilinx device to use without
having to compile the design on a Xilinx device ?

Thanks,
Prashant

Article: 45542
Subject: Re: logic elements v/s logic cells
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 25 Jul 2002 16:40:19 -0700
Links: << >>  << T >>  << A >>

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

Prashant,

The number of LUTS and CLBs vs LEs don't map easily, as we also make
better use of what we have.  Basically, a smaller part would fit the
larger design due to architectual efficiencies.

Now that I have gone way out of my expertise (Peter is out for a few
weeks on vacation), I will state that any of our FAEs or sales reps can
fill you in on the architectual reasons why we just make better use of
what we have, in effect reducing customer costs even further.

Beyond just a simple LUT to LE comparsion, one must also take into
account the dual port RAM, SRL16, the DLLs, etc. which all have a good
effect on further reducing the amount of logic required.  This will
further increase the overall efficiency than just the logic alone.

Of course, one must not only re-target the design, but in some cases
take advantage of the structures that are present in order to realize
all of the efficiencies  (not to mention running it through the tools
with similar effort settings:  no fair to compare running their tools
for weeks with our tools for once through - or vica versa).

Austin

Prashant wrote:

> Hi,
> I have the LE count of a design in Altera's Apex20KE1500E device. I
> need to know what Xilinx device will this design fit in. Is there a
> relationship between the logic elements of Altera and logic cells of
> Xilinx ? How can one decide which exact Xilinx device to use without
> having to compile the design on a Xilinx device ?
>
> Thanks,
> Prashant



Article: 45543
Subject: Re: RLOC Origin problems in ISE4.2sp3?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 26 Jul 2002 00:45:49 GMT
Links: << >>  << T >>  << A >>
Bret,

Thanks for your reply.  I generally use the default HSETs
because it is considerably less effort than working with the
explicit sets, especially if you have code that is reused
among many projects (the RLOCs are embedded in the VHDL
source).   It is interesting to note that the floorplanner,
if used with the ucf flow puts the RLOC ORIGIN constraint at
the bottom of the hierarchy as well, which is where I got
the particular RLOC_ORIGIN to begin with.  I hadn't realized
that putting the RLOC origin on an element that is not at
the top level of the hset would create a new hset.  Anyway,
the problem is now solved.

Does putting the RLOC Origin lower in the hierarchy work in
5.1 then?


Bret Wade wrote:

>
>
> Ray Andraka wrote:
>
>> I tried the RLOC origin on a smaller macro in the
>> design, and it works fine
>> in that case.  The failing macro has tiles which come
>> from a different edif
>> netlist.  It is a fairly large macro as well (24x80
>> slices).  The size
>> and/or the fact that its netlist comes from nested edif
>> files may be
>> contributing factors.  The odd thing is that the
>> RLOC_ORIGIN is recognized
>> in the editable view of the floorplanner (which pulls
>> it's info from the ucf
>> and ngd files), but is being ignored in place and route.
>
> Hello Ray,
>
> I've taken a look at your design and have found two
> factors contributing to the vanishing RLOC_ORIGIN
> constraint:
>
> 1. Your macro specification is using the default H_SET set
> grouping. It turns out that the RLOC_ORIGIN is itself used
> to define sets and because you are applying it to a FF at
> the bottom of the hierarchy, that FF is being broken out
> into a separate single component macro, which I assume is
> not your intention. The solution which has been
> communicated to you by the hotline, is to move the
> RLOC_ORIGIN constraint to the hierarchy level that is the
> start of your H_SET. Another solution would be to apply
> HU_SET constraints to all of the instances you do want in
> the macro rather that relying on the implied H_SET
> grouping.
>
> From the constraints guide:
> All design elements with RLOC constraints at a single node
> of the design hierarchy are considered to be in the same
> H_SET set unless they are tagged with another type of set
> constraint such as RLOC_ORIGIN or RLOC_RANGE. If you
> explicitly tag any element with an RLOC_ORIGIN,
> RLOC_RANGE, U_SET, or HU_SET constraint, it is removed
> from an H_SET set. Most designs contain only H_SET
> constraints, since they are the underlying mechanism for
> relationally placed macros. The RLOC_ORIGIN or RLOC_RANGE
> constraints are discussed further in the "Fixing Members
> of a Set at Exact Die Locations" section.
>
> 2. There is a known problem in 4.2i where RLOC_ORIGIN
> constraints on single component RPMs are dropped. This
> problem is described in Xilinx Answer 12192. This explains
> why the RLOC_ORIGIN constraint did not result in a
> corresponding MACRO LOCATE constraint in the PCF file.
> This problem has been fixed in version 5.1i. I have
> confirmed that using your design
>
> Regards,
> Bret Wade
> Xilinx Product Applications

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin
Franklin, 1759



Article: 45544
Subject: Re: logic elements v/s logic cells
From: Ray Andraka <ray@andraka.com>
Date: Fri, 26 Jul 2002 00:56:42 GMT
Links: << >>  << T >>  << A >>
Each Altera LE is basically a 4 input LUT plus a D flip-flop.  In the
current Xilinx families (excluding the 4000/spartanI series), there are
2 four input LUTs per slice, so a rough equivalence is two Altera LEs
per Xilinx slice.  That is only part of the story though, each family
has features, that if you take advantage of them can tip the balance.
The Xilinx slices shine in DSP type applications because the arithmetic
is more robust and because the LUT can be used as a 16 bit shift
register instead of logic.  The arithmetic robustness comes from the
fact that the Altera 4 LUTis decimated into a pair of 3-LUTs when used
in arithmetic mode (one ofr sum one for carry), where Xilinx has
separate dedicated carry logic.  The result is that you can pack more
function into one level of logic.  Xilinx also has some extra
multiplexers that select LUT outputs to get larger muxes for almost free
(although, they do not match the bit pitch of arithmetic, so they can be
of limited value in high performance arithmetic circuits).

Some Altera devices have CAM memory, and the "DSP block" in stratix
looks like it will make stiff competition for VIrtexII.

The easiest way is to count LUTs, but paying attention to how arithmetic
gets implemented and to potential use of SRL16s.

Prashant wrote:

> Hi,
> I have the LE count of a design in Altera's Apex20KE1500E device. I
> need to know what Xilinx device will this design fit in. Is there a
> relationship between the logic elements of Altera and logic cells of
> Xilinx ? How can one decide which exact Xilinx device to use without
> having to compile the design on a Xilinx device ?
>
> Thanks,
> Prashant

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 45545
Subject: Re: Xilinx ISE 4.2i Is A Step Backwards! Beware!!!
From: "Jeff Cunningham" <jcc@sover.net>
Date: Thu, 25 Jul 2002 22:14:17 -0400
Links: << >>  << T >>  << A >>

> ISE 4.2 seems like a big step backwards. What happened? Are others
> having troubles with 4.2?

I have a Spartan-2 design in VHDL that will crunch just fine under 4.1 but
immediatly dies in XST in 4.2 with the infamous
"FATAL_ERROR:Xst:Portability/export/Port_main.h:116.1.9.4.1 error message,
or as I call it, the "I'm too lame a synthesizer to give you a real error
message" error.

Also I've noticed that the 4.1 XST gives a lot of warnings that do not get
flagged in 4.2, at least in my case - stuff like basic sensitivity list
warnings.


> I am very disappointed in Xilinx and in ISE 4.2. Are we doing
> something wrong, or is a 4.2 a step backwards???

So far I have to say XST is a step backwards in 4.1.

-Jeff





Article: 45546
Subject: Re: logic elements v/s logic cells
From: Kevin Brace <killspam4kevinbraceusenet@killspam4hotmail.com>
Date: Thu, 25 Jul 2002 21:16:17 -0500
Links: << >>  << T >>  << A >>
Prashant,

Although I haven't played around with APEX20K line (I have some
experience with FLEX10KE. Compared to Spartan-II, it's an unforgiving
chip.), I will guess that APEX20K's LE is less efficient when it comes
to packing unrelated LUTs and FFs compared to Virtex family's CLB.
That's because like what Ray (Ray Andraka) said, LE's 4-input LUT will
be reduced to a 3-input LUT when you want the LE's LUT and FF to be
independent.
If I elaborate further, I guess what I am trying to say is that unless
the 4-input LUT's output is connected to the FF within the same LE, you
cannot use the 4-input LUT and the FF at the same time, however, you can
use the 3-input LUT and the FF at the same time, but that isn't nice.
The reason the LE's 4-input LUT gets reduced to a 3-input LUT is because
"data 3" input of the 4-input LUT is also tied to LE's FF (Check the
APEX20K datasheet for details.).
        However, if you look at Virtex datasheet's detailed view of a
Slice (1 CLB = 2 Slices), BX or BY input or 4-input LUT's output can
connect to a FF, and BX or BY input are not tied to the 4-input LUT's F1
through F4 inputs, which means that you have a much better chance of
having an unrelated LUT and FF together within the same Slice.
I suppose, when BX or BY input is tied to a FF, it looks like to me you
won't be able to use an F5MUX (A multiplexer that ties two 4-input LUTs
to recreate a 4:1 MUX or a 5-input LUT.), but since most synthesis tools
cannot seem to take advantage of F5MUX anyway, that shouldn't be a huge
penalty.
I do wonder, does anyone use F5MUX?
Perhaps, shouldn't Xilinx get rid of it?
        Going back to the LE's efficiency, I won't be surprised if you
need 20% more LUTs or FFs in APEX20K family than in Virtex family just
to fit the same circuit, even if your application doesn't do much
arithmetic (i.e., Mostly random logic.).



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)



Prashant wrote:
> 
> Hi,
> I have the LE count of a design in Altera's Apex20KE1500E device. I
> need to know what Xilinx device will this design fit in. Is there a
> relationship between the logic elements of Altera and logic cells of
> Xilinx ? How can one decide which exact Xilinx device to use without
> having to compile the design on a Xilinx device ?
> 
> Thanks,
> Prashant

Article: 45547
Subject: Re: TMS 1000
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 25 Jul 2002 19:34:09 -0700
Links: << >>  << T >>  << A >>
"Spehro Pefhany" <speff@interlog.com> writes:
> Right. I predict this so-called "TMS 1000" will be a miserable failure in
> the marketplace with such shoddy design. 

Monthly unit shipments of the TMS 1000 seems to be 0 at the moment.  It remains
to be seen whether the numbers will increase over time.

Article: 45548
Subject: Re: hold time
From: Kevin Brace <killspam4kevinbraceusenet@killspam4hotmail.com>
Date: Thu, 25 Jul 2002 21:35:48 -0500
Links: << >>  << T >>  << A >>
        Assuming that you don't know much about hold time (I didn't have
a good understanding of hold time myself only a few months ago. So,
someone correct me if I am wrong.), having hold time (positive hold
time) means that the input signal is reaching the FF before the clock
edge is striking the FF.
So, to prevent the input signal from reaching the FF too early, what you
will have to do is to put some delay between the input pin and the FF
input (Slowing down the signal.).
If the input signal is reaching the FF after the clock strikes, then you
are having zero or negative hold time, which is what you want.
Use of IOB input FF should solve the hold time problem you are talking
about, even if you don't use a built-in DLL, because IOB's input FF has
some programmable delay that's greater than the GCLK's clock
distribution delay.
Also, is the clock coming in through a dedicated GCLKx pin?
If not, that might make the hold time problem worse because the clock
distribution delay will be large compared to using the dedicated GCLKx
pin.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)



Anjan wrote:
> 
> I am interfacing a DSP to xilinx fpga. The DSP writes to a fifo in the
> fpga. The timing report gives very good setup time but large hold
> time. The DSP doesn't introduce hold time but can have wait states.
> Can any one suggest a way in which I can reduce the hold time
> requirement.
> Anjan

Article: 45549
Subject: Re: Xilinx ISE 4.2i Is A Step Backwards! Beware!!!
From: Kevin Brace <killspam4kevinbraceusenet@killspam4hotmail.com>
Date: Thu, 25 Jul 2002 21:46:12 -0500
Links: << >>  << T >>  << A >>
Not only that, when the design hierarchy (Keep Hierarchy) is kept, XST
still cannot convert regular Verilog tri-state buffers (i.e., assign
My_Pin = My_OE ? 1'bz : My_Output;) buried inside a submodule to IOBUF
or OBUFT, unless the design hierarchy is flattened, or IOBUF or OBUFT is
explicitly instantiate in the design.
However, in some case where a blackbox is used in a design, flattening
the hierarchy has resulted in XST messing up the synthesis (I have seen
valid FFs getting dropped from the design . . .).
Hopefully, ISE 5.1's XST will solve the problem, but my expectation
isn't too high since these problems have existed since WebPACK ISE
3.3WP8.0's XST (XST Ver. D.27) as far as I know.


Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)



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