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 35400

Article: 35400
Subject: Re: comp.arch.fpga : Unusual clock divider ckt
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Wed, 03 Oct 2001 06:16:53 -0000
Links: << >>  << T >>  << A >>

>That is in the nature of DDS.
>Max jitter = one clock period.
>If that is acceptable, go for it.

Somehow, it seems as though I should be able to get close to
a half clock period.  Closer "just" takes more bits of state.

What am I missing?

-- 
These are my opinions, not necessarily my employeers.  I hate spam.


Article: 35401
Subject: Re: Barrel Shifter
From: NotMe <not-given@invalid.com>
Date: Wed, 03 Oct 2001 06:30:40 GMT
Links: << >>  << T >>  << A >>
I'm with Ray on this.  

First on the tight design thing.  Back in 1990-1991 I spent ages reverse 
engineering where the bits in a XC2064 bitstream were that held the LUT 
contents.  It turned out that there were all kinds of funky modes for 
the LUT that affected which bits went where, sometimes bits got 
inverted, and so on; it took months.  Eventually I managed to get this 
working and was able to make awesomely fast constant bus comparators 
where the constant was settable by software at configuration time by 
dynamic bitsream modification.  I could also set per-configuration modes 
for my logic without having the overhead of addressable storage to 
control the modes.  It even interrogated the Xilinx toolflow output 
files to map CLB names to placed CLB locations.  I was real pleased with 
myself.

Then I realized that I was stuck on 2000 series stuff unless I wanted to 
reproduce all that hard work on 3000 and then 4000, in fact over the 
medium term all of that effort ended up holding back the product, 
(although boy, it was cool :) )  So it was we were using 2064s until 
they were end-of-lifed, while the 'less cool' competition was on 4000s 
kicking my butt.

After I realized what I had *really* done to myself, I swore off of 
extreme performance optimization at the cost of generality.

Second, although it is really the same point in disguise, on the 
schematic vs text thing, Ray is right that the VHDL should be able to 
express anything you can express using schematics.  This is pretty clear 
from the fact that both the VHDL and the schematic are turned into the 
same form of netlist as their first step in the toolflow.

I was using a very early version of Orcad, at some huge cost, on my 
super duper 8086 640x480 monochrome machine, so I have some experience 
of schematic entry (and in fact I continue to use Protel for designing 
PCBs).  Just think back to the last time you had to reorder a bus that 
you had unwisely drawn all the lines in for and you'll have to admit 
that text, with all the amenities available in a good editor beats out 
all the area management dross in 2D schemtics.  And if you say to 
yourself, 'ha! that ain't fair, as I use bus member labelling for 
connectivity without the lines', then consider that you are in fact 
using plain text to replace schematic elements.

Now having said that, I also believe that some people have a greater 
facility with images than text and others are vice versa.  So long as 
the content of the schematic uses retartgetable primitives then it is 
probably defensible to go on using schematics.  But there are real 
advantages to pure text, all the advantages that software people know 
and love.  I know I would rather have a bunch of proven VHDL components 
than a stack of proven schematics.



|I have been using VHDL for about 2 years now, and this is for some very 
high speed
|designs (eg. our FFT module, which is the fastest single thread FFT 
available for
|FPGAs is done in VHDL).  VHDL does let you structurally instantiate 
primitives, so
|that you can do anything you can do with schematics, plus it has the 
advantage of
|a generate statement, so one design can cover many uses.  For example, 
our adder
|macro creates a fully RLOC'd adder that is automatically sized to the 
the width of
|the bus connected to its output.  When we did schematics, this required 
a separate
|schematic for each bit width (we had ways of doing that quickly too, 
but the
|generate is even better).  We were a relatively late adopter of VHDL 
because we
|didn't start using it heavily until we could put placement in the 
hierarchical
|source (the tools did not allow it until roughly 2nd qtr 1999).
|
|One thing that I won't do is use more than one entry tool on a 
particular
|project.  Most customers wouldn't tolerate having to buy seats of two 
different
|tools in order to maintain a design that could have been done with just 
one tool.
|
|
|Duane Hague wrote:
|
|> To be a bit less subtle, my point was that IMO schematic entry should
|> remain part of the designers tool kit.  HDL synthesizers use an 
"N-bit"
|> modular translation approach because it would be too complex to 
include
|> optimization for all cases of "input width" versus "architecture 
element
|> width".  I would suggest that the designer needs to be aware of the
|> advantages and disadvantages of each entry method and to select the
|> method most appropriate to each portion of the design.  Over many 
years
|> of experience, I have lost trust in anyone who proposes "the magic
|> answer where one size fits all" (i.e. certain HDL True Believers).
|>
|> With regards to "reuse":  If your EDA tools do not support both HDL 
and
|> schematic entry as well as mixed entry modes; I would argue that you
|> need to consider the use of other EDA tools!  I would not be happy 
with
|> any EDA tools that did not allow more than one mode of design entry.
|>
|> Respectfully,
|> Duane Hague
--
Posted using Nographer - News in your Browser
http://www.nographer.com - free, open source, and smart


Article: 35402
Subject: Re: comp.arch.fpga : Unusual clock divider ckt
From: Ray Andraka <ray@andraka.com>
Date: Wed, 03 Oct 2001 12:11:15 GMT
Links: << >>  << T >>  << A >>
The error which manifests itself as jitter is due to truncation of lower
bits, which is done to get a square wave out.  The error is bounded by
+1,-0, which is why I said a maximum of one clock period.

Hal Murray wrote:

> >That is in the nature of DDS.
> >Max jitter = one clock period.
> >If that is acceptable, go for it.
>
> Somehow, it seems as though I should be able to get close to
> a half clock period.  Closer "just" takes more bits of state.
>
> What am I missing?
>
> --
> These are my opinions, not necessarily my employeers.  I hate spam.

--
--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: 35403
Subject: Re: Virtex II current consumption
From: hamish@cloud.net.au
Date: Wed, 03 Oct 2001 12:33:52 GMT
Links: << >>  << T >>  << A >>
Phil Hays <spampostmaster@home.com> wrote:
> I suggest trying the new XPower utility.  It seems to produce much better
> estimates, at least from the starting point of a routed NCD and a simulation.

It's a good utility, but a bit unwieldy. I fed in my XC2V6000 design
(37% utilised so far), and a VCD file of about 100us of simulation
(which was nearly a 500Mb file). XPower took almost two hours
to load in the VCD and process it.

I'd be a bit more confident if it wasn't (at least partly) written in Java.

Anyway, I don't have any idea if the figure I got is any good,
but it seems plausible.


regards,
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 35404
Subject: Re: Virtex II current consumption
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 03 Oct 2001 14:59:03 +0100
Links: << >>  << T >>  << A >>


hamish@cloud.net.au wrote:

> Phil Hays <spampostmaster@home.com> wrote:
> > I suggest trying the new XPower utility.  It seems to produce much better
> > estimates, at least from the starting point of a routed NCD and a simulation.
>
> It's a good utility, but a bit unwieldy. I fed in my XC2V6000 design
> (37% utilised so far), and a VCD file of about 100us of simulation
> (which was nearly a 500Mb file). XPower took almost two hours
> to load in the VCD and process it.
>
> I'd be a bit more confident if it wasn't (at least partly) written in Java.
>
> Anyway, I don't have any idea if the figure I got is any good,
> but it seems plausible.
>
> regards,
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

The use of VCD is what's put me off XPower so far. It strikes me that any decent
power estimate is going to need a lot longer run than 100usec although that will be
very much design dependent. If so then there are really only 3 options:

o Do short runs excercising different functional areas and ``glue'' them together
in some fashion to get a final estimate. Should keep the VCD sizes down at the
expense of accuracy.

o Generate some humongous VCD and post-process it before feeding it into XPower in
a more useful format.

o Change format from VCD to ???.

<hobby-horse on>
IMO VCD is either the most brilliantly insane thing ever invented or the most
insanely brilliant; portability taken to a logical but lunatic extreme. I can
remember how easily early versions of GTKWave handled the ~1GB VCD files I was
being presented with i.e. not at all.
<hobby-horse off>


Article: 35405
Subject: Re: Which Cable for the Xilinx 3064XL ?
From: Magnus Homann <d0asta@licia.dtek.chalmers.se>
Date: 03 Oct 2001 16:24:06 +0200
Links: << >>  << T >>  << A >>
Peter Alfke <peter.alfke@xilinx.com> writes:

> Before anybody wastes time looking for the part number:
> There never was an XC3064XL. But there is/was an XC3064L, a 3.3-V version of the
> XC3064A. 

Maybe he was referring to the XCR3064XL?

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 35406
Subject: Virtex II DCM: Phase Shifting
From: "Eric Mullaley" <eric.mullaley@amirix.com>
Date: Wed, 3 Oct 2001 07:46:05 -0700
Links: << >>  << T >>  << A >>
I have seen previous discussions involving phase shifting limits of the DCMs. Apparently you cannot go beyond + or - 255. But is 255 the number that should be used, or should it be smaller if the clock speed excedes 90 Mhz? I am trying to design an application at 350 MHz.

The clock period at that speed is 2.857 ns. The minimum granularity of the phase shifter is between 40 and 50 ps. If this number is 50 ps, you could only do 57 shifts before completing a full 360 degree phase shift. Does this mean that the DCM will hang up after + or - 57 phase shifts? Or can it do 255 phase shifts, leading to a full 1600 degree phase shift in either direction?

Eric Mullaley

Article: 35407
Subject: Re: Virtex II DCM: Phase Shifting
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 03 Oct 2001 08:46:10 -0700
Links: << >>  << T >>  << A >>
Eric,

The phase shift delay line is physically limited to <10 ns.  This means than at frequencies higher than ~100 MHz, you have full range control.  At frequencies less than that, you will have less range, and a PS OVERFLOW will occur when you reach the beginning, or end of the line.

The 10 ns number is specified with some margin (obviously) so at frequencies below 100 MHz, you may find complete range -- but don't count on every device having that behavior.

Austin

Eric Mullaley wrote:

> I have seen previous discussions involving phase shifting limits of the DCMs. Apparently you cannot go beyond + or - 255. But is 255 the number that should be used, or should it be smaller if the clock speed excedes 90 Mhz? I am trying to design an application at 350 MHz.
>
> The clock period at that speed is 2.857 ns. The minimum granularity of the phase shifter is between 40 and 50 ps. If this number is 50 ps, you could only do 57 shifts before completing a full 360 degree phase shift. Does this mean that the DCM will hang up after + or - 57 phase shifts? Or can it do 255 phase shifts, leading to a full 1600 degree phase shift in either direction?
>
> Eric Mullaley


Article: 35408
Subject: Re: Virtex II DCM: Phase Shifting
From: John_H <johnhandwork@mail.com>
Date: Wed, 03 Oct 2001 15:47:33 GMT
Links: << >>  << T >>  << A >>
Austin helped fill in the blanks for me...
My understanding is that the DCM knows how many taps it takes to make up a period.  The phase value you give it is the approximate fraction of that period.  At your high clock rate, each increment or decrement of the phase won't necessarily change which tap is used.  If it takes 5 increments to advance one tap, the DCM won't change the tap 4 out of 5 times.

It's all scaled to one period, whether faster than 50pS*255 or slower.

- John


Eric Mullaley wrote:

> I have seen previous discussions involving phase shifting limits of the DCMs. Apparently you cannot go beyond + or - 255. But is 255 the number that should be used, or should it be smaller if the clock speed excedes 90 Mhz? I am trying to design an application at 350 MHz.
>
> The clock period at that speed is 2.857 ns. The minimum granularity of the phase shifter is between 40 and 50 ps. If this number is 50 ps, you could only do 57 shifts before completing a full 360 degree phase shift. Does this mean that the DCM will hang up after + or - 57 phase shifts? Or can it do 255 phase shifts, leading to a full 1600 degree phase shift in either direction?
>
> Eric Mullaley


Article: 35409
Subject: Xilinx Foundation vs. ISE
From: Richard Dungan <postmaster@[127.0.0.1]>
Date: Wed, 03 Oct 2001 18:46:16 +0100
Links: << >>  << T >>  << A >>
Hi all.

I'm running Xilinx Foundation Base Express (the one with VHDL added on).
I've used this for several years and by remembering to pay for support,
I've avoided getting drawn into the time-based licence thing.

I received a letter recently from Xilinx, telling me that Foundation
4.1i is about to ship. All well and good.

The letter goes to some length to extol the virtues of Xilinx' new ISE
package, and I'm curious as to the pros and cons of moving over to this.

Things that particularly concern me are:

1) What are the licence implications? I understand that Foundation is to
   be canned in due course. When it becomes ISE *only* will I suddenly
   be expected to buy a time-based licence?

2) What kind of support does ISE give to schematic entry? I foresee an
   ongoing need for this (partly driven from outside) for some time to
   come. This may include updates to Foundation projects.

Any opinions would be welcome.

Richard

------------Richard Dungan-------------
Radix Electronic Designs, Orpington, UK
   richardATradixDASHdesignDOTcoDOTuk
---------------------------------------

Article: 35410
Subject: Re: Xilinx Foundation vs. ISE
From: "stefaan vanheesbeke" <stefaan.vanheesbeke@pandora.be>
Date: Wed, 03 Oct 2001 20:07:24 GMT
Links: << >>  << T >>  << A >>

It seems that the schematics are not compatible!!! And as the my local
application engineer from AVNET says : there is no conversion program
available, and there will never be a conversion program available.

The thing is, Xilinx wants everyone to use VHDL and/or Verilog. Here is the
good point, the XST synthesiser has no 'node locked' and or 'time'
restrictions. So I think (and I hope) once installed, you never have to look
again for new license files, ... as for example for the synopsys stuff.

The bad thing is that I've used synopsys until now and while converting a
project from foundation to ISE, I saw that the syntax to include
constraints(like the contents of a RAM block) in HDL (verilog in my case) is
different with the XST compiler. So you are fucked anyway, either schematic
or HDL is not fully compatible.

On the other hand, you cannot wait to start using the latest software for
new things, otherwise the gap is getting bigger and bigger. Xilinx wants to
sell mare and more bigger components, so the need bigger and bigger
software. I think Xilinx (and also Altera) wants to go faster to new
technologies than most of their customers, but everyone is forced to follow
them. This is the bat thing about only two really big companys on the top of
the programmable logic mountain.

See you,

Stefaan


"Richard Dungan" <postmaster@[127.0.0.1]> schreef in bericht
news:fdgmrt4apvaejfmq3ksgmhracbu5fhj9t4@4ax.com...
> Hi all.
>
> I'm running Xilinx Foundation Base Express (the one with VHDL added on).
> I've used this for several years and by remembering to pay for support,
> I've avoided getting drawn into the time-based licence thing.
>
> I received a letter recently from Xilinx, telling me that Foundation
> 4.1i is about to ship. All well and good.
>
> The letter goes to some length to extol the virtues of Xilinx' new ISE
> package, and I'm curious as to the pros and cons of moving over to this.
>
> Things that particularly concern me are:
>
> 1) What are the licence implications? I understand that Foundation is to
>    be canned in due course. When it becomes ISE *only* will I suddenly
>    be expected to buy a time-based licence?
>
> 2) What kind of support does ISE give to schematic entry? I foresee an
>    ongoing need for this (partly driven from outside) for some time to
>    come. This may include updates to Foundation projects.
>
> Any opinions would be welcome.
>
> Richard
>
> ------------Richard Dungan-------------
> Radix Electronic Designs, Orpington, UK
>    richardATradixDASHdesignDOTcoDOTuk
> ---------------------------------------



Article: 35411
Subject: Re: Barrel Shifter
From: "stefaan vanheesbeke" <stefaan.vanheesbeke@pandora.be>
Date: Wed, 03 Oct 2001 20:21:22 GMT
Links: << >>  << T >>  << A >>
hi,

I think it depends so much of the design itself, that you cannot give a
general rule.

Sometimes, a nice looking top level done in schematic entry is better than
just some text files. Specially if you are working with more people on a
project, everyone has a nice overview of the global design.

Sometimes you need the other way. Especially when you cannot enter
constraints in the HDL code (cfr Ray Andraka). I did a processor 2 years ago
and the alu was done in schematic, converted to EDIF and then placed and
routed toghether with the other parts. There was now way to tell the
synthsise tool to make a fast enough design for me or the pass the RLOC
constraints to the par tool.

Also a thing to consider : what is the important thing on what part of the
design : is it the best timing and placement theoretically possible, or the
fastest development or a mixture of both? I learned to make a working system
in a reasonable time and with the acceptance of the fact that it can be done
better, and faster, and nicer, and... but you have to make decisions on what
is important.



"Duane Hague" <dhague@neo.rr.com> schreef in bericht
news:MPG.1623f404e41478c3989681@news-server.neo.rr.com...
> In article <3BB9E8C7.4CA8327D@flukenetworks.com>,
> mike.treseler@flukenetworks.com says...
> > Duane Hague wrote:
> >
> > >         By chance, I happened to have just tried designing a 32-bit
barrel
> > > shifter (0-31 shift, 5-bit shift index) in MaxPlus with schematic
entry
> > . . .
> >
> > > Conclusion:  Could this be a nice example of why a designer should
have
> > > more than "one arrow in his quiver"?
> >
> > Certainly you can't beat packing your own primitives
> > for speed and gate count.
> >
> > But consider that a barrel shifter might be less
> > than 1% of a large design.
> >
> > And you might want to reuse the design in 2 years
> > on newer devices.
> >
> >        -- Mike Treseler
> >
> To be a bit less subtle, my point was that IMO schematic entry should
> remain part of the designers tool kit.  HDL synthesizers use an "N-bit"
> modular translation approach because it would be too complex to include
> optimization for all cases of "input width" versus "architecture element
> width".  I would suggest that the designer needs to be aware of the
> advantages and disadvantages of each entry method and to select the
> method most appropriate to each portion of the design.  Over many years
> of experience, I have lost trust in anyone who proposes "the magic
> answer where one size fits all" (i.e. certain HDL True Believers).
>
> With regards to "reuse":  If your EDA tools do not support both HDL and
> schematic entry as well as mixed entry modes; I would argue that you
> need to consider the use of other EDA tools!  I would not be happy with
> any EDA tools that did not allow more than one mode of design entry.
>
> Respectfully,
> Duane Hague



Article: 35412
Subject: error from BUFGMUX in ModelSim??
From: "Ultimate Bob" <bongarda@msu.edu>
Date: Wed, 3 Oct 2001 17:57:07 -0400
Links: << >>  << T >>  << A >>
I am trying to use a BUFGMUX in Xilinx webpack 4.1 and Modelsim xe 5.5b
(starter) and I get the following message.


# Model Technology ModelSim XE vcom 5.5b Compiler 2001.05 May 23 2001
# -- Loading package standard
# -- Compiling architecture behavioral of test
# -- Loading package std_logic_1164
# -- Loading package std_logic_arith
# -- Loading package std_logic_unsigned
# -- Loading package vital_timing
# -- Loading package vcomponents
# -- Loading entity test
# ERROR: test.vhd(58): Cannot load design unit: unisim.bufgmux
# Cannot open file:
F:/xilinx_webpack/modeltech_xe/win32xoem/../xilinx/vhdl/unisim/bufgmux/_prim
ary.dat
# ERROR: test.vhd(58): VHDL Compiler exiting
# ERROR: F:/xilinx_webpack/modeltech_xe/win32xoem/vcom failed.
# Error in macro ./test_tb.fdo line 8
# F:/xilinx_webpack/modeltech_xe/win32xoem/vcom failed.
#     while executing
# "vcom -skip e -93 -explicit   test.vhd"


The section of my code that may be of interest is as follows


component BUFGMUX
  port (
   I0   : in std_logic;
        I1   : in std_logic;
        S    : in std_logic;
        O    : out std_logic
 );
end component;


and...


U1: BUFGMUX
  port map (
 I0     => zero, -- insert clock input used when select (S) is Low
 I1     => clk, -- insert clock input used when select (S) is High
 S      => ena, -- insert Mux-Select input
 O      => bufclk  -- insert clock output
 );


and ...


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

--
-- synopsys translate_off
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;
-- synopsys translate_on
--


Thanks,
Theron Hicks



Article: 35413
Subject: Re: error from BUFGMUX in ModelSim?? Sorry wrong address...
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Wed, 03 Oct 2001 17:59:45 -0400
Links: << >>  << T >>  << A >>


Theron Hicks wrote:

> I am trying to use a BUFGMUX in Xilinx webpack 4.1 and Modelsim xe 5.5b
> (starter) and I get the following message.
>
> # Model Technology ModelSim XE vcom 5.5b Compiler 2001.05 May 23 2001
> # -- Loading package standard
> # -- Compiling architecture behavioral of test
> # -- Loading package std_logic_1164
> # -- Loading package std_logic_arith
> # -- Loading package std_logic_unsigned
> # -- Loading package vital_timing
> # -- Loading package vcomponents
> # -- Loading entity test
> # ERROR: test.vhd(58): Cannot load design unit: unisim.bufgmux
> # Cannot open file:
> F:/xilinx_webpack/modeltech_xe/win32xoem/../xilinx/vhdl/unisim/bufgmux/_prim
> ary.dat
> # ERROR: test.vhd(58): VHDL Compiler exiting
> # ERROR: F:/xilinx_webpack/modeltech_xe/win32xoem/vcom failed.
> # Error in macro ./test_tb.fdo line 8
> # F:/xilinx_webpack/modeltech_xe/win32xoem/vcom failed.
> #     while executing
> # "vcom -skip e -93 -explicit   test.vhd"
>
> The section of my code that may be of interest is as follows
>
> component BUFGMUX
>   port (
>    I0   : in std_logic;
>         I1   : in std_logic;
>         S    : in std_logic;
>         O    : out std_logic
>  );
> end component;
>
> and...
>
> U1: BUFGMUX
>   port map (
>  I0     => zero, -- insert clock input used when select (S) is Low
>  I1     => clk, -- insert clock input used when select (S) is High
>  S      => ena, -- insert Mux-Select input
>  O      => bufclk  -- insert clock output
>  );
>
> and ...
>
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
> --
> -- synopsys translate_off
> library UNISIM;
> use UNISIM.VCOMPONENTS.ALL;
> -- synopsys translate_on
> --
>
> Thanks,
> Theron Hicks


Article: 35414
Subject: What's a process?
From: jmrice@ntlworld.com (Martin Rice)
Date: 3 Oct 2001 15:21:41 -0700
Links: << >>  << T >>  << A >>
Having written some teaching materials based on ABEL and XPLA development system
I'm now trying to convert to VHDL and Webpack.

Here's a very introductory ABEL design:

MODULE  basic_gates
TITLE   'two-way demultiplexer'

DECLARATIONS
clock, control	pin 43,14;	"clock, push switch
X, Y		pin 16,27; 	"left, right LEDs

EQUATIONS

X = control & clock;
Y = !control & clock;

END

As an introduction to a different way (behavioural?) of thinking I
point out that there is a when-then-else solution:

EQUATIONS

when (control == 0) then X = clock;
else Y = clock;

END

These both work fine.

In VHDL I can get this to work:

entity basic_gates is
port 
(
  clock,control : in bit;
  X,Y : out bit
);
end basic_gates;

architecture how_it_works of basic_gates is
begin
  X <= clock when control = '1' else '0';
  Y <= clock when control = '0' else '0';
end how_it_works;

...but this won't:

architecture how_it_works of basic_gates is
begin
  process(control,clock)
  begin
    if control = '1' then X <= clock; 
    else Y <= clock;
    end if;
  end process;
end how_it_works;

Am I doing something fundamentally wrong? Why can't I use the if-then-else 
syntax except in a process?  Is a process appropriate for a combinational 
problem?  Have I got the right signals in the sensitivity list?

Many thanks.

Article: 35415
Subject: [OT] Prototyping with BGA's
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Wed, 03 Oct 2001 22:42:45 GMT
Links: << >>  << T >>  << A >>
Does anyone have links to info on prototyping with BGA packages?  I'm trying
to figure out what tools to buy and what the PCB layout requirements might
be for the lager BGA FPGA's.

Thanks,

--
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net     where    "0_0_0_0_"  =  "ecinema"




Article: 35416
Subject: Virtex II multiplier speed?
From: Bob Perlman <bob@cambriandesign.com>
Date: Wed, 03 Oct 2001 22:45:03 GMT
Links: << >>  << T >>  << A >>
Hi - 

Can someone give me a rough speed estimate for the 18-by-18
multipliers in the Virtex II parts?  I plan to drive the inputs from
block RAM outputs or registers; the outputs will go directly to
registers.  Enabling the internal pipeline register would be fine,
too.  In the interests of keeping the cost finite, the target device
is a -4 speed grade.

I'd experiment with PAR myself, but I'm still waiting for 4.1.

Thanks,
Bob Perlman
Cambrian Design Works


Article: 35417
Subject: Re: Barrel Shifter
From: Ray Andraka <ray@andraka.com>
Date: Thu, 04 Oct 2001 00:02:54 GMT
Links: << >>  << T >>  << A >>
You can do RLOCs in VHDL, at least with synplicity and leonardo, and have been
able to for about 2.5 years now.  If you couldn't, I wouldn't be using VHDL.
Not only can you put RLOCs in, you can also use user attributes to put in TNMs,
BLKNMs, initial values and whatever else you want.  The key for these critical
circuits is to treat the synthesizer as a generator rather than a synthesizer.
Works like a charm.

By doing this for a hierarchical library, you eventually get a set of commonly
used macros that are optimized RPMs that you can instantiate in your RTL code.
That way you get both fast development AND fast performance.  I miss the visual
presentation of schematics, but that is about it.

stefaan vanheesbeke wrote:

> hi,
>
> I think it depends so much of the design itself, that you cannot give a
> general rule.
>
> Sometimes, a nice looking top level done in schematic entry is better than
> just some text files. Specially if you are working with more people on a
> project, everyone has a nice overview of the global design.
>
> Sometimes you need the other way. Especially when you cannot enter
> constraints in the HDL code (cfr Ray Andraka). I did a processor 2 years ago
> and the alu was done in schematic, converted to EDIF and then placed and
> routed toghether with the other parts. There was now way to tell the
> synthsise tool to make a fast enough design for me or the pass the RLOC
> constraints to the par tool.
>
> Also a thing to consider : what is the important thing on what part of the
> design : is it the best timing and placement theoretically possible, or the
> fastest development or a mixture of both? I learned to make a working system
> in a reasonable time and with the acceptance of the fact that it can be done
> better, and faster, and nicer, and... but you have to make decisions on what
> is important.
>
> "Duane Hague" <dhague@neo.rr.com> schreef in bericht
> news:MPG.1623f404e41478c3989681@news-server.neo.rr.com...
> > In article <3BB9E8C7.4CA8327D@flukenetworks.com>,
> > mike.treseler@flukenetworks.com says...
> > > Duane Hague wrote:
> > >
> > > >         By chance, I happened to have just tried designing a 32-bit
> barrel
> > > > shifter (0-31 shift, 5-bit shift index) in MaxPlus with schematic
> entry
> > > . . .
> > >
> > > > Conclusion:  Could this be a nice example of why a designer should
> have
> > > > more than "one arrow in his quiver"?
> > >
> > > Certainly you can't beat packing your own primitives
> > > for speed and gate count.
> > >
> > > But consider that a barrel shifter might be less
> > > than 1% of a large design.
> > >
> > > And you might want to reuse the design in 2 years
> > > on newer devices.
> > >
> > >        -- Mike Treseler
> > >
> > To be a bit less subtle, my point was that IMO schematic entry should
> > remain part of the designers tool kit.  HDL synthesizers use an "N-bit"
> > modular translation approach because it would be too complex to include
> > optimization for all cases of "input width" versus "architecture element
> > width".  I would suggest that the designer needs to be aware of the
> > advantages and disadvantages of each entry method and to select the
> > method most appropriate to each portion of the design.  Over many years
> > of experience, I have lost trust in anyone who proposes "the magic
> > answer where one size fits all" (i.e. certain HDL True Believers).
> >
> > With regards to "reuse":  If your EDA tools do not support both HDL and
> > schematic entry as well as mixed entry modes; I would argue that you
> > need to consider the use of other EDA tools!  I would not be happy with
> > any EDA tools that did not allow more than one mode of design entry.
> >
> > Respectfully,
> > Duane Hague

--
--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: 35418
Subject: Re: What's a process?
From: "Jeff Cunningham" <jcc@sover.net>
Date: Wed, 3 Oct 2001 22:29:24 -0400
Links: << >>  << T >>  << A >>

Martin Rice <jmrice@ntlworld.com> wrote in message
news:e00c15a3.0110031421.7f0ba99b@posting.google.com...
> Having written some teaching materials based on ABEL and XPLA development
system
> I'm now trying to convert to VHDL and Webpack.

> ...

> architecture how_it_works of basic_gates is
> begin
>   X <= clock when control = '1' else '0';
>   Y <= clock when control = '0' else '0';
> end how_it_works;

> ...but this won't:
>
> architecture how_it_works of basic_gates is
> begin
>   process(control,clock)
>   begin
>     if control = '1' then X <= clock;
         Y<='0';  -- ADD THIS
>     else Y <= clock;
          X<='0';  -- AND THIS
>     end if;
>   end process;
> end how_it_works;

> Am I doing something fundamentally wrong?
Without the '0' assignments, you have turned X and Y into latches. In
general, if a combinatorial process can execute without assigning a value to
a signal, the synthesizer will infer a latch (and usually issue a warning
also)

> Why can't I use the if-then-else syntax except in a process?
Because by definition in VHDL if-then-else is sequential code and sequential
code is only allowed in a process (or procedure or function).

> Is a process appropriate for a combinational problem?
yes

>Have I got the right signals in the sensitivity list?
yes

Note that your two forms are equivalent for synthesis but in simulation they
will function slightly differently (and "incorrectly") if the signal control
has other values (like 'X' or 'Z').

Check out comp.lang.vhdl and track down the FAQ associated with that ng.
Also any introductory VHDL book should cover these subjects.

Jeff





Article: 35419
Subject: Re: comp.arch.fpga : Unusual clock divider ckt
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Thu, 04 Oct 2001 03:08:28 GMT
Links: << >>  << T >>  << A >>
On Wed, 03 Oct 2001 06:16:53 -0000, hmurray-nospam@megapathdsl.net
(Hal Murray) wrote:

>
>>That is in the nature of DDS.
>>Max jitter = one clock period.
>>If that is acceptable, go for it.
>
>Somehow, it seems as though I should be able to get close to
>a half clock period.  Closer "just" takes more bits of state.
>
>What am I missing?

Another way of looking at this is to think about the output of the NCO
as being a square wave at some frequency that has been sampled by the
NCO clock.

If the frequency of the square wave is the NCO clock divided by an
integer, then the sampling process will produce 0 jitter.
For most frequencies though, the sampling process produces jitter of
up to a clock period.
Please take the time to look at the jitter measurements that I posted
earlier in this thread.

***
There's a simple modification that halves this jitter.  It does
require a 50% duty cycle clock and one falling edge flip flop though.
Email for code.

Regards,
Allan.

Article: 35420
Subject: Re: Which Cable for the Xilinx 3064XL ?
From: "Martin Fischer" <Martin.Fischer@fzi.de>
Date: Thu, 4 Oct 2001 09:24:08 +0200
Links: << >>  << T >>  << A >>
Yes, sorry I found no CPLD Newsgroup.

It's the XCR3064XL Coolrunner and I think, the
Parallel JTEG Download Cable should function with
the 3,3V. And the Software finds the Cable, but can't
identify the CPLD.

Thanks

Martin.Fischer@fzi.de


"Magnus Homann" <d0asta@licia.dtek.chalmers.se> schrieb im Newsbeitrag
news:ltpu844xa1.fsf@licia.dtek.chalmers.se...
> Peter Alfke <peter.alfke@xilinx.com> writes:
>
> > Before anybody wastes time looking for the part number:
> > There never was an XC3064XL. But there is/was an XC3064L, a 3.3-V
version of the
> > XC3064A.
>
> Maybe he was referring to the XCR3064XL?
>
> Homann
> --
> Magnus Homann, M.Sc. CS & E
> d0asta@dtek.chalmers.se



Article: 35421
Subject: Re: Xilinx Foundation vs. ISE
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Thu, 4 Oct 2001 09:56:48 +0200
Links: << >>  << T >>  << A >>
So, essentially, what you are saying is that, given I have quite a big
design which I DEFINATELY do not want to lose, it would be wise to hold off
on upgrading
to 4.1 until I have finished with my design? Is there someone here from
Xilinx who could give a definitive answer?

adrian



> It seems that the schematics are not compatible!!! And as the my local
> application engineer from AVNET says : there is no conversion program
> available, and there will never be a conversion program available.
>
> The thing is, Xilinx wants everyone to use VHDL and/or Verilog. Here is
the
> good point, the XST synthesiser has no 'node locked' and or 'time'
> restrictions. So I think (and I hope) once installed, you never have to
look
> again for new license files, ... as for example for the synopsys stuff.
>
> The bad thing is that I've used synopsys until now and while converting a
> project from foundation to ISE, I saw that the syntax to include
> constraints(like the contents of a RAM block) in HDL (verilog in my case)
is
> different with the XST compiler. So you are fucked anyway, either
schematic
> or HDL is not fully compatible.
>
> On the other hand, you cannot wait to start using the latest software for
> new things, otherwise the gap is getting bigger and bigger. Xilinx wants
to
> sell mare and more bigger components, so the need bigger and bigger
> software. I think Xilinx (and also Altera) wants to go faster to new
> technologies than most of their customers, but everyone is forced to
follow
> them. This is the bat thing about only two really big companys on the top
of
> the programmable logic mountain.
>
> See you,
>
> Stefaan
>
>
> "Richard Dungan" <postmaster@[127.0.0.1]> schreef in bericht
> news:fdgmrt4apvaejfmq3ksgmhracbu5fhj9t4@4ax.com...
> > Hi all.
> >
> > I'm running Xilinx Foundation Base Express (the one with VHDL added on).
> > I've used this for several years and by remembering to pay for support,
> > I've avoided getting drawn into the time-based licence thing.
> >
> > I received a letter recently from Xilinx, telling me that Foundation
> > 4.1i is about to ship. All well and good.
> >
> > The letter goes to some length to extol the virtues of Xilinx' new ISE
> > package, and I'm curious as to the pros and cons of moving over to this.
> >
> > Things that particularly concern me are:
> >
> > 1) What are the licence implications? I understand that Foundation is to
> >    be canned in due course. When it becomes ISE *only* will I suddenly
> >    be expected to buy a time-based licence?
> >
> > 2) What kind of support does ISE give to schematic entry? I foresee an
> >    ongoing need for this (partly driven from outside) for some time to
> >    come. This may include updates to Foundation projects.
> >
> > Any opinions would be welcome.
> >
> > Richard
> >
> > ------------Richard Dungan-------------
> > Radix Electronic Designs, Orpington, UK
> >    richardATradixDASHdesignDOTcoDOTuk
> > ---------------------------------------
>
>



Article: 35422
Subject: Re: Which Cable for the Xilinx 3064XL ?
From: Magnus Homann <d0asta@licia.dtek.chalmers.se>
Date: 04 Oct 2001 10:15:03 +0200
Links: << >>  << T >>  << A >>
"Martin Fischer" <Martin.Fischer@fzi.de> writes:

> Yes, sorry I found no CPLD Newsgroup.

No problem, you're in the right group.

> It's the XCR3064XL Coolrunner and I think, the
> Parallel JTEG Download Cable should function with
> the 3,3V. And the Software finds the Cable, but can't
> identify the CPLD.

You need either the old XPLA Programmer (available with the 3.1i
tools), or the new iMPACT (available with the 4.1i tools).

iMPACT is also available as a free download from 

http://www.support.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack

I hope this helps.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 35423
Subject: Xilinx: JTAG parallel connection problem
From: "Sebastian" <novalid@ress>
Date: Thu, 4 Oct 2001 10:34:51 +0200
Links: << >>  << T >>  << A >>
Hi Group

My iMPACT program can not establish communication with the cable when trying
to reach the JTAG chain.

My setup is straightforward: a standard pc with ecp+epp printerport, windows
2000 and the small Virtex2 evaluation board connected to the parallel port.
I'm using Xilinx ISE4.

The cable, power, etc. are all properly connected. What can be the cause? Do
i need to make specific port settings in Windows?

thanx in advance,
regards,
Sebastian



Article: 35424
Subject: multipliers in virtex-II
From: visu_paduchuri@yahoo.com (viswanath)
Date: 4 Oct 2001 02:30:11 -0700
Links: << >>  << T >>  << A >>
How to use built-in multipliers in virtex-II?
Do I need to use any libraries from xilinx?

Rgds,
visu



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