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 37800

Article: 37800
Subject: Re: Best-case timing?
From: Bob Perlman <no-spam@sonic.net>
Date: Thu, 20 Dec 2001 19:23:43 GMT
Links: << >>  << T >>  << A >>
On Thu, 20 Dec 2001 18:19:54 GMT, Andy Peters
<andy@exponentmedia.nospam.com> wrote:

>Bob Perlman wrote:
>
>> On Wed, 19 Dec 2001 17:19:58 GMT, Andy Peters
>> <andy@exponentmedia.nospam.com> wrote:
>> 
>> 
>>>Stephen Byrne wrote:
>>>
>>>
>>>>I originally posted this yesterday on google groups, but I'm not seeing it
>>>>on my home news server.  In case it is not visible to all, I'm reposting.
>>>>
>>>>Hello All,
>>>>
>>>>My company is currently comparing 66MHz PCI core solutions from Xilinx
>>>>and Altera, as well as debating using a home-spun core.  One issue
>>>>I've come upon is the PCI requirement for a MAX clock-to-out time of 6
>>>>ns and MIN clock-to-out time of 2 ns.  Both the Xilinx ISE and Altera
>>>>Quartus II tools seem very helpful in supplying MAX (worst-case) Tco
>>>>times, but I don't see any info on best-case times.  Apparently the
>>>>SDF files for back-annotated timing sim have the same worst-case
>>>>numbers repeated 3 times, resulting in the same simulation regardless
>>>>of case selection.  My question is: how is anyone (FPGA vendors
>>>>included) guaranteeing a MIN Tco of 2 ns across all conditions and
>>>>parts if the design tools don't even yield that information?
>>>>
>>>
>>>You like to live dangerously if you depend on best-case timing information.
>>>
>> 
>> What's the alternative?
>
>
>
>Um, worst-case timing information?

Worst-case timing information isn't a substitute for best-case timing
information; you need both.  If you're trying to calculate setup
margin, you need the worst-case clock-to-Q time of the driving device.
But if you're trying to calculate the hold margin, you need the
best-case (i.e., shortest) clock-to-Q time.  That's why Stephen Byrne
was looking for best-case timing.

Bob Perlman


Article: 37801
Subject: Re: Clock pins in Virtex-E
From: "H.L" <alphaboran@yahoo.com>
Date: Thu, 20 Dec 2001 21:24:26 +0200
Links: << >>  << T >>  << A >>
Hi Peter,
I am using 3 clocks with the same frequency because my FPGA interfaces with
other modules whose outputs are my input clocks. I put all the input data
from these modules in registers synchronized with the corresponding input
clock and later I synchronized the data with my FPGA's clock. Its something
I could not avoid.
I have some problems with the timing constraints but I believe I have just
found a possible cause. My main problem still remains the one I have
described above with the FPGA EXPRESS.

Harris

"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
news:3C222D3C.A63B8107@xilinx.com...
>
>
> "H.L" wrote:
>
> > Hello all and Merry Christmas,
> > I have a small question. I work in a Virtex-E FPGA, my model has 4
clocks (3
> > in 155MHz and the other one slower~100MHz) as inputs.
>
> Why do you have 3 clocks with the same frequency? Use only one!
> But if the phases or frequencies are not identical, then be very careful
when
> you cross from one frequency domain to the other
>
> > In the ucf file I
> > located all clocks in the GCK pins, is that right?
>
> Yes
>
> >
> > If yes, is this the only constraint that ensures proper distribution of
the
> > signals?
>
> Yes, you always get very good, low-skew distribution on the global clocks.
>
> >
> > Ah , and another one :) .. one of the processes (VHDL coding) in my
model
> > that i want to implement uses the falling edge of the slow clock while
the
> > others use the rising edge of all clocks, is this going to be a problem?
>
> No problem
>
> Peter Alfke
>
>



Article: 37802
Subject: Re: Barrel shifter puts three 2->1 muxes / slice in Xilinx
From: Frederic Rivoallon <frederic.rivoallon@xilinx.com>
Date: Thu, 20 Dec 2001 11:29:15 -0800
Links: << >>  << T >>  << A >>

Carl Brannen wrote:

> ....  I haven't figured out how to apply an attribute to a generated component
> (i.e. like your
> RLOC usage on generated components).  I'm assuming here that "generated" means
> the use of the "generate" command in VHDL.  The basic problem is that I haven't
> figured out how to properly address the components.  So I went ahead and
> instantiated them individually.
>
> If you have a way around that, I'd appreciate the secret.
>

Check this link (How to Attach Attributes Inside of Generate?):
http://tech-www.informatik.uni-hamburg.de/vhdl/doc/faq/FAQ1.html#attributes

Frédéric


Article: 37803
Subject: Clock pins in Virtex-E
From: "H.L" <alphaboran@yahoo.com>
Date: Thu, 20 Dec 2001 11:30:24 -0800
Links: << >>  << T >>  << A >>
Hello all and Merry Christmas,
I have a small question. I work in a Virtex-E FPGA, my model has 4 clocks (3
in 155MHz and the other one slower~100MHz) as inputs. In the ucf file I
located all clocks in the GCK pins, is that right?
If yes, is this the only constraint that ensures proper distribution of the
signals?
Ah , and another one :) .. one of the processes (VHDL coding) in my model
that i want to implement uses the falling edge of the slow clock while the
others use the rising edge of all clocks, is this going to be a problem?

Thanks
Harris



Article: 37804
Subject: Re: You take the low road and I'll ......
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 20 Dec 2001 11:31:13 -0800
Links: << >>  << T >>  << A >>
Well,

I guess I am wrong then.

Along with 99% of the others.

We'll just have to cope the best we can.

Austin

Pete Dudley wrote:

> Austin F. is right on the value of schematics vs. hdl and Austin L. is
> wrong. It's best to use schematics to design the architectural hierarchy and
> only use HDL within blocks where it makes sense.
>
> When an HDL is used structurally you have to maintain a graphical block
> diagram (schematic) on the side to keep track of how it all fits together.
> In any case most schematic tools will write out a structural VHDL netlist
> automatically if you're required to provide a pure HDL design.
>
> HDL's have many valuable characteristics like portability but they have been
> oversold as productivity enhancers.
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3C20F7F0.CCE642F6@andraka.com...
> > Both schematics and HDL can be horrendous or stellar.  I've seen examples
> both
> > ways of both.  In either case, proper use of hierarchy is the key to a
> > maintainable design.
> >
> > Austin Franklin wrote:
> >
> > > Hi Austin,
> > >
> > > > If I see hdl code, at least I can see where it is going, even if it is
> > > written
> > > > badly.
> > >
> > > For me, that is not true.  I have to wade around pages and pages of
> > > text....where with a schematic, I can pick up what's going on almost
> > > instantly.  Schematics offer, if done right that is, a built-in block
> > > diagram...which can not be done with text files very easily.  The data
> flow
> > > is FAR easier to pick out in a schematic than in HDL, and control logic
> may
> > > or may not be easier to "understand" in HDL...it depends on how it's
> done.
> > >
> > > > Nice thing about software is that people have figured out how to
> manage
> > > it, and
> > > > document it.
> > >
> > > Why is that any different than schematics?
> > >
> > > > If I examine a design, from top to bottom, I can make a determination
> of
> > > the
> > > > quality of the design by examining the hdl code.  It is possible, but
> more
> > > > difficult to see what is going on in schematic.
> > >
> > > I believe the exact opposite.
> > >
> > > > As a
> > > > technical manager, code review is one tool that should be used to make
> > > sure the
> > > > project is on track, following the rules, and has a higher likelihood
> of
> > > > success.
> > >
> > > And you've never seen/done a schematic review?  I believe schematics are
> FAR
> > > easier to review than text files are.  Anyway, design reviews are
> typically
> > > NOT the source files, but the architecture...it's rare that one brings
> > > source files to a design review and gives a copy to everyone in the
> room,
> > > and people just sit around flipping through hundreds of pages of text
> > > discussing constructs...
> > >
> > > I think you should attend my lecture in the spring on mixed design entry
> for
> > > FPGA design ;-)
> > >
> > > Regards,
> > >
> > > Austin
> >
> > --
> > --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: 37805
Subject: Re: How to initialize the block ram of xilinx SpartanII FPGA?(Verilog)
From: Ray Andraka <ray@andraka.com>
Date: Thu, 20 Dec 2001 19:34:27 GMT
Links: << >>  << T >>  << A >>
Personally, I prefer to instantiate my own.  It gives me the capability
to a) place them in my code and b) more flexibility in the use, and
initialization.

The BRAMs have a default initialization of all zeros.  To change that in
both the bitstream and the simulation you need to initialize them twice:
(I'll stick with the VHDL explanation).   For simulation, you need to
set the INIT= generics in the model to the desired initialization
values.  These are in the form of a bit_vector for VHDL.  For synthesis,
the generics need to be made invisible to the synthesizer (it doesn't
know how to apply generics to a black box).  To initialize the RAMs for
synthesis, you need to add INIT= attributes matching the generics.  The
INIT= attribute strings are hex strings, so you'll need a conversion
between the two formats.

kh05168 wrote:

> Use Coregen. It is quite straightforward.

--
--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: 37806
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: Tim Hubberstey <sendme@no.spam>
Date: Thu, 20 Dec 2001 19:39:58 GMT
Links: << >>  << T >>  << A >>
"S. Ramirez" wrote:
> 
> "Bret Wade" <bret.wade@xilinx.com> wrote in message
> news:3C212A10.D5E82114@xilinx.com...
> > Simon,
> >
> > Okay, but you could use the IOB attribute and then there would be no
> worries
> > about whether you've set the Map options correctly.
> >
> > Regards,
> > Bret
> 
> Bret,
>      This is just a suggestion from a user point of view -- change the
> default.  Then we wouldn't be having this discussion.
> Simon

You could change the default but then you'll break things for those
people who need the FFs to not be packed. There are cases when you might
not want your FFs in the IOBs, e.g. extra hold time needed for inputs
and/or outputs.

This is why, IMHO, tools should always have command line flags for all
states of an option. The tool should also echo a complete command line
with all options enumerated so that the command can be recreated later,
ideally in a script.
-- 
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . .  VHDL, ASICs, FPGAs, embedded systems

Article: 37807
Subject: Re: Best-case timing?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 21 Dec 2001 08:47:02 +1300
Links: << >>  << T >>  << A >>
Bob Perlman wrote:
> 
> On Thu, 20 Dec 2001 18:19:54 GMT, Andy Peters
> <andy@exponentmedia.nospam.com> wrote:
> 
> >Bob Perlman wrote:
> >
> >> On Wed, 19 Dec 2001 17:19:58 GMT, Andy Peters
> >> <andy@exponentmedia.nospam.com> wrote:
> >>
> >>
> >>>Stephen Byrne wrote:
> >>>
> >>>
> >>>>I originally posted this yesterday on google groups, but I'm not seeing it
> >>>>on my home news server.  In case it is not visible to all, I'm reposting.
> >>>>
> >>>>Hello All,
> >>>>
> >>>>My company is currently comparing 66MHz PCI core solutions from Xilinx
> >>>>and Altera, as well as debating using a home-spun core.  One issue
> >>>>I've come upon is the PCI requirement for a MAX clock-to-out time of 6
> >>>>ns and MIN clock-to-out time of 2 ns.  Both the Xilinx ISE and Altera
> >>>>Quartus II tools seem very helpful in supplying MAX (worst-case) Tco
> >>>>times, but I don't see any info on best-case times.  Apparently the
> >>>>SDF files for back-annotated timing sim have the same worst-case
> >>>>numbers repeated 3 times, resulting in the same simulation regardless
> >>>>of case selection.  My question is: how is anyone (FPGA vendors
> >>>>included) guaranteeing a MIN Tco of 2 ns across all conditions and
> >>>>parts if the design tools don't even yield that information?
> >>>>
> >>>
> >>>You like to live dangerously if you depend on best-case timing information.
> >>>
> >>
> >> What's the alternative?
> >
> >
> >
> >Um, worst-case timing information?
> 
> Worst-case timing information isn't a substitute for best-case timing
> information; you need both.  If you're trying to calculate setup
> margin, you need the worst-case clock-to-Q time of the driving device.
> But if you're trying to calculate the hold margin, you need the
> best-case (i.e., shortest) clock-to-Q time.  That's why Stephen Byrne
> was looking for best-case timing.
> 
> Bob Perlman

 Seems a terminology problem. 
 BOTH the shortest and longest time delays can be considered 'worst
case', 
from a statistical and tolerance sense.

 'Best-case' is to have all devices right in the middle of the error
band :-) 

 It's no different from lowest and highest Vcc, for example.

 Many systems actually rely on the silicon tracking.
On many data sheets, if you applied shortest and longest limits,
often the chip cannot ( technically ) drive itself!
 Fortunately in the real world, you do not get 'opposite corner' 
effects on one die.

-jg

Article: 37808
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: Alan Nishioka <alann@accom.com>
Date: Thu, 20 Dec 2001 11:57:50 -0800
Links: << >>  << T >>  << A >>
I also found that the Synplify syn_useioff attribute didn't always work. 
 I think it was because Synplify was violating the rules about putting 
FF's in the IOB so par couldn't put them there.  I have not tried it 
recently;  I now instantiate an FD on every IO.  I tried many different 
ways to make an inferred register work.  I used syn_keep for a while. 
 Then I upgraded Synplify and it all stopped working.  With the FD, it 
has continued to work through several upgrades of Synplify and par.

And just to answer the original question, I always set the pr -b flag. 
 I don't see how you can use an FPGA without it (and get repeatable high 
speed timing).

Alan Nishioka
alann@accom.com


Austin Franklin wrote:

>Hi Ken,
>
>If you read what I wrote in my reply, you would note that I mentioned the
>syn_useioff "attribute" and also said that you still need the "pr -b"
>option, as just the attribute alone does not put the FFs in the IOBs...at
>least in the tool set I have been using...
>
>Regards,
>
>Austin
>
>"Ken McElvain" <ken@synplicity.com> wrote in message
>news:3C221CDB.2060207@synplicity.com...
>
>>Synplify does have a syn_useioff attribute that you can
>>set to 1 as a global attribute.  This will default all
>>packable boundary flip-flops into the IOB by putting the
>>IOB attribute on them.  You can then override the default
>>on a pin by pin basis with the same attribute.
>>


Article: 37809
Subject: Re: Clock pins in Virtex-E
From: none <no@email.supplied>
Date: Thu, 20 Dec 2001 20:18:58 GMT
Links: << >>  << T >>  << A >>
Hi Harris,

I use FPGA Express too but as an integrated part of the Foundation
Toolset. I do have constraints editor on Express but don't really feel the
need to use it, I think you can get perfectly workable results without
tweaking there, writing your code to force the synthesis you want and
controlling the timing from the Xilinx implementation tool.

The .ucf file is actually used by the Xilinx implementation tool, not the
synth tool. I don't know if Alliance is the same as Foundation in this
respect but when you create a project in Foundation, the tool creates a
dummy template for your project. This contains just about everything you
need to timespec your design. The ucf file can just be edited in a text
editor and the tools should pick up the default <project_name>.ucf.from
the projects directory. There's also a copy of the template in the Xillinx
directory structure somewhere.

You can find out more about ucf files by using the _advanced_ search at
support.xilinx.com

Fred


Article: 37810
Subject: Re: Spartan-IIE schematic symbol?
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 20 Dec 2001 13:11:54 -0800
Links: << >>  << T >>  << A >>
"Austin Franklin" <austin@dark98room.com> writes:
> Typically, the schematic symbol isn't a "canned" symbol, it is a custom
> symbol tailored to the function/pinout of the FPGA.  They don't take THAT
> long to make if you know the tool...
> 
> Does anyone here **really** use a "canned" symbol for their FPGAs?  For a
> PAL, yes, but an FPGA?

I don't even like canned symbols for PALs.  I almost always draw a custom
symbol.

Article: 37811
Subject: Re: Best-case timing?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 20 Dec 2001 13:38:04 -0800
Links: << >>  << T >>  << A >>


Jim Granville wrote:

>  Many systems actually rely on the silicon tracking.
> On many data sheets, if you applied shortest and longest limits,
> often the chip cannot ( technically ) drive itself!
>  Fortunately in the real world, you do not get 'opposite corner'
> effects on one die.
>

Inside the chip delay tracking is an acceptable assumption, but not in the I/O.
The driver and receiver are different chips, and can be at the extremes of
processing tolerances, and may not have exactly the same Vcc and temperature.

That's why we now spec not only max input set-up, but also min set-up aka "negative
hold time".
And, sooner or later, you will also see min clock-to-out specs.

One problem is to measure these, the other problem is that engineering and
processing work very hard to defeat these "best case" parameter limits by making
the chip even better = faster. And nobody wants to stop that laudable effort  ;-)

Peter Alfke



Article: 37812
Subject: Re: You take the low road and I'll ......
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 20 Dec 2001 21:40:01 +0000
Links: << >>  << T >>  << A >>


Austin Lesea wrote:

> Well,
>
> I guess I am wrong then.
>
> Along with 99% of the others.
>
> We'll just have to cope the best we can.
>
> Austin
>
>

There is a curious phenomenon on this NG whereby any thread that lasts long enough
always converges on one of 2 discussion ``attractors''

- Schem vs. HDL.

- Verilog vs. VHDL.

strange.




Article: 37813
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 20 Dec 2001 21:50:31 +0000
Links: << >>  << T >>  << A >>


Alan Nishioka wrote:

> I also found that the Synplify syn_useioff attribute didn't always work.
>  I think it was because Synplify was violating the rules about putting
> FF's in the IOB so par couldn't put them there.  I have not tried it
> recently;  I now instantiate an FD on every IO.  I tried many different
> ways to make an inferred register work.  I used syn_keep for a while.
>  Then I upgraded Synplify and it all stopped working.  With the FD, it
> has continued to work through several upgrades of Synplify and par.
>

You are correct. It can be a total PITA to presuade Synplify to not violate
the packing rules.
It can be done but the kludges can be ugly . I've got a little perl script
that parses the MAP report file & checks that all input & output FFs, except
for a small list,  have been packed.

And, as far as I can see, it gets worse when the FF concerned is not inferred
at the top level of a ``synthesise everything all at once'' design approach
but may be 1/2 levels down in a more modular design. Then, AFAIK, syn_useioff
is just ignored.



Article: 37814
Subject: Re: You take the low road and I'll ......
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 20 Dec 2001 14:14:48 -0800
Links: << >>  << T >>  << A >>
Rick,

That's It!  Chaos Theory, again!  I knew it all along.  We can predict how many emails
in any thread it takes to get to the three strange attactor points:  dropped (everyone
ignores it), VHDL vs verilog, schematic vs hdl, altera vs xilinx, fpga vs asic, ....

Austin

Rick Filipkiewicz wrote:

> Austin Lesea wrote:
>
> > Well,
> >
> > I guess I am wrong then.
> >
> > Along with 99% of the others.
> >
> > We'll just have to cope the best we can.
> >
> > Austin
> >
> >
>
> There is a curious phenomenon on this NG whereby any thread that lasts long enough
> always converges on one of 2 discussion ``attractors''
>
> - Schem vs. HDL.
>
> - Verilog vs. VHDL.
>
> strange.


Article: 37815
Subject: Re: You take the low road and I'll ......
From: "Bryan" <bryan@srccomp.com>
Date: Thu, 20 Dec 2001 15:24:38 -0700
Links: << >>  << T >>  << A >>
Yeah, the funny thing is that I started most of this bickering in the
thread.  But I didn't want to argue, I just wanted an answer to my hand
routing question.  It worked, mud slinging got enough interest that my
particular question was answered.  Now that is funny :>

Bryan



> There is a curious phenomenon on this NG whereby any thread that lasts
long enough
> always converges on one of 2 discussion ``attractors''
>
> - Schem vs. HDL.
>
> - Verilog vs. VHDL.
>
> strange.
>
>
>



Article: 37816
Subject: Re: Barrel shifter puts three 2->1 muxes / slice in Xilinx
From: "Carl Brannen" <carl.brannen@terabeam.com>
Date: Thu, 20 Dec 2001 23:11:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
Frédéric, that link is much appreciated, and though I haven't tried it yet, I
believ it will do the trick.

Carl

> > 
> Check this link (How to Attach Attributes Inside of Generate?):
> http://tech-www.informatik.uni-hamburg.de/vhdl/doc/faq/FAQ1.html#attributes
> 
> Frédéric




-- 
Posted from firewall.terabeam.com [216.137.15.2] 
via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 37817
Subject: Re: Barrel shifter puts three 2->1 muxes / slice in Xilinx
From: Ray Andraka <ray@andraka.com>
Date: Thu, 20 Dec 2001 23:20:15 GMT
Links: << >>  << T >>  << A >>
Since this seems to come up fairly frequently, here is a simple example of RLOCs
applied as an attribute inside the generate.  The itoa function is a homebrew
function that converts an integer into an ascii string.  If your synthesizer
recognizes 'image, you could use that instead.  The attributes have to be assigned in
the same level of code as the labels they are being assigned to are due to
visibility.  In otherwords, components inside a generate are not visible outside the
generate, so the attributes have to be in the generate's declaration section.

   LEN:for i in 0 to bits-1 generate
         constant row :natural:=((width-1)/2)-(i/2);
         constant column:natural:=0;
         constant slice:natural:=0;
         constant rloc_str : string := "R" & itoa(row) & "C" & itoa(column) & ".S" &
itoa(slice);
         attribute RLOC of U1: label is rloc_str;
    begin

         U1: FDE port map (
              Q  => dd(j),
              D  => ff_d,
              C  => clk,
              CE =>lcl_en(en_idx));
   end generate LEN;


Frederic Rivoallon wrote:

> Carl Brannen wrote:
>
> > ....  I haven't figured out how to apply an attribute to a generated component
> > (i.e. like your
> > RLOC usage on generated components).  I'm assuming here that "generated" means
> > the use of the "generate" command in VHDL.  The basic problem is that I haven't
> > figured out how to properly address the components.  So I went ahead and
> > instantiated them individually.
> >
> > If you have a way around that, I'd appreciate the secret.
> >
>
> Check this link (How to Attach Attributes Inside of Generate?):
> http://tech-www.informatik.uni-hamburg.de/vhdl/doc/faq/FAQ1.html#attributes
>
> Frédéric

--
--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: 37818
Subject: Re: You take the low road and I'll ......
From: Ray Andraka <ray@andraka.com>
Date: Thu, 20 Dec 2001 23:32:56 GMT
Links: << >>  << T >>  << A >>
I think using both in the same design, at least for a consultant doing designs for
a client, is a sin among sins.  It requires the client to obtain and maintain two
tool flows if he wishes to do anything with the design without having to come back
to you.  Pick one and stick with it for the whole design.

We've moved to VHDL and abandoned schematics because a) that is what the customer
wants, b) the VHDL generate allows us to make a parameterized library that is much
more complete, easier to maintain, and easier to use than what we had with
schematics.  We've gained archives that can be read on a text editor, and much
better simulation capabilities in exchange for ready made block diagrams, and a
bit more time to grok the design, especially if it was not documented with more
text than code.  I find myself doing block diagrams on scraps of paper.  With the
addition of an RTL diagram generator, the scales tip in favor of VHDL for us.

Austin Lesea wrote:

> Well,
>
> I guess I am wrong then.
>
> Along with 99% of the others.
>
> We'll just have to cope the best we can.
>
> Austin
>
> Pete Dudley wrote:
>
> > Austin F. is right on the value of schematics vs. hdl and Austin L. is
> > wrong. It's best to use schematics to design the architectural hierarchy and
> > only use HDL within blocks where it makes sense.
> >
> > When an HDL is used structurally you have to maintain a graphical block
> > diagram (schematic) on the side to keep track of how it all fits together.
> > In any case most schematic tools will write out a structural VHDL netlist
> > automatically if you're required to provide a pure HDL design.
> >
> > HDL's have many valuable characteristics like portability but they have been
> > oversold as productivity enhancers.
> >
> > "Ray Andraka" <ray@andraka.com> wrote in message
> > news:3C20F7F0.CCE642F6@andraka.com...
> > > Both schematics and HDL can be horrendous or stellar.  I've seen examples
> > both
> > > ways of both.  In either case, proper use of hierarchy is the key to a
> > > maintainable design.
> > >
> > > Austin Franklin wrote:
> > >
> > > > Hi Austin,
> > > >
> > > > > If I see hdl code, at least I can see where it is going, even if it is
> > > > written
> > > > > badly.
> > > >
> > > > For me, that is not true.  I have to wade around pages and pages of
> > > > text....where with a schematic, I can pick up what's going on almost
> > > > instantly.  Schematics offer, if done right that is, a built-in block
> > > > diagram...which can not be done with text files very easily.  The data
> > flow
> > > > is FAR easier to pick out in a schematic than in HDL, and control logic
> > may
> > > > or may not be easier to "understand" in HDL...it depends on how it's
> > done.
> > > >
> > > > > Nice thing about software is that people have figured out how to
> > manage
> > > > it, and
> > > > > document it.
> > > >
> > > > Why is that any different than schematics?
> > > >
> > > > > If I examine a design, from top to bottom, I can make a determination
> > of
> > > > the
> > > > > quality of the design by examining the hdl code.  It is possible, but
> > more
> > > > > difficult to see what is going on in schematic.
> > > >
> > > > I believe the exact opposite.
> > > >
> > > > > As a
> > > > > technical manager, code review is one tool that should be used to make
> > > > sure the
> > > > > project is on track, following the rules, and has a higher likelihood
> > of
> > > > > success.
> > > >
> > > > And you've never seen/done a schematic review?  I believe schematics are
> > FAR
> > > > easier to review than text files are.  Anyway, design reviews are
> > typically
> > > > NOT the source files, but the architecture...it's rare that one brings
> > > > source files to a design review and gives a copy to everyone in the
> > room,
> > > > and people just sit around flipping through hundreds of pages of text
> > > > discussing constructs...
> > > >
> > > > I think you should attend my lecture in the spring on mixed design entry
> > for
> > > > FPGA design ;-)
> > > >
> > > > Regards,
> > > >
> > > > Austin
> > >
> > > --
> > > --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
> > >
> > >

--
--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: 37819
Subject: Re: annoying problem and "simple and clever solution"
From: Ray Andraka <ray@andraka.com>
Date: Thu, 20 Dec 2001 23:46:50 GMT
Links: << >>  << T >>  << A >>
Heck, I was using that trick with 3000 series parts driving wired ORs
back in the early '90s.  The problem was to eliminate the rise time on a
shared bus (I think it was a DACK on a motorola processor)

Peter Alfke wrote:

>
> Peter Alfke wrote:
>
>> What if you have to drive 5-V that has a CMOS input threshold of up
>> to 3.5 V.
>> Then you need a pull-up resistor to the 5 V, and you should
>> configure the
>> XC4005 output as "open collector" ( really: open drian ). That costs
>> you speed,
>> since you now have a 1 kilohm pull-up and a, say, 100 pF lad, which
>> creates a
>> 100 ns delay time constant.
>> There is a simple and clever way around that, and I can send you the
>> circuit
>> description on Monday when I am back at work.
>
> Here is the "simple and clever circuit" description and the whole,
> somewhat long-winded explanation, first published 3 years ago.
> Today the 3 ns rise-time is more like 1 ns...
>
>
> XC4000XL Driving 5-V CMOS Inputs
>
>  The XC4000XL devices use 3.3 V supply, but tolerate 5 V on their I/O
>  pins.  They can drive 5-V TTL-level inputs directly.  For driving 5-V
>
>  CMOS-level inputs, a pull-up resistor to 5 V is required, and the
>  XC4000XL output must be 3-stated when High.
>
>  (If the output were to remain active High, the pull-up resistor would
>
>  fight the <50 Ohm output transistor, and the output voltage would be
>  only 100 mV above the Vcc of 3.3 V.)
>
>  The required output structure is commonly called “open collector” or,
>
>  more correctly, “open drain,” and this function is easily generated
>  inside the chip by driving the Data and the active-Low Output Enable
>  signal of the output block together.  The external Low-to-High
>  transition is then driven only by the pull-up resistor.  A 470 Ohm
> pull-up
>  resistor to 5 V and a 50 pF load capacitance create a 0.4-to-4.5 V
> rise
>  time of >40 ns.
>
>  For a faster rise time, drive the internal active-Low Output Enable
>  signal not directly from the internal data signal, but from a 2-input
>
>  AND gate driven by the internal data signal AND the input signal that
>
>  comes back from the same device output pin.  On the rising edge, this
>
>  assures that the output pull-up transistor is active for most of the
> rise
>  time, resulting in a shorter output delay.  The important part of the
> rise
>  time, from 0.4 to 3.0V, is reduced dramatically, from 20 ns to 3 ns.
>  Watch out for ringing, it might pull the signal down again.
>
>  In most cases, the fast active edge gets you through the CMOS
>  threshold and the propagation delay is then <3 ns.  At worst, the
>  additional pull-up from the resistor is still needed to reach the
>  threshold voltage reliably, but you still saved at least 15 ns.
>
>  This idea originated with our European FAEs (Ken Chapman and Nick
>  Sawyer).   We recently performed experiments to verify the claim.  It
>
>  works splendidly.
> Peter Alfke, Xilinx 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: 37820
Subject: Re: annoying problem and "simple and clever solution"
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 20 Dec 2001 16:19:16 -0800
Links: << >>  << T >>  << A >>
Note:
We did not file a patent,
did not even write an app note ( mistake! )
nor a magazine article ( even bigger mistake ).

It's nice to know that smart guys think alike...

Meryy Christmas
Peter Alfke
=======================================
Ray Andraka wrote:

> Heck, I was using that trick with 3000 series parts driving wired ORs
> back in the early '90s.  The problem was to eliminate the rise time on a
> shared bus (I think it was a DACK on a motorola processor)
>


Article: 37821
Subject: Re: Hardware FPGA questions
From: Kevin Brace
Date: Thu, 20 Dec 2001 18:29:47 -0600
Links: << >>  << T >>  << A >>
If I add my two cents to this question, as a Xilinx Spartan-II user (a
low cost version of Virtex. From what I see, it is sold at 1/3 of the
price of the equivalent density Virtex) struggling to get my PCI IP core
to meet mere 33MHz PCI timings (Tsu < 7ns . . . is hard to meet at least
in my case), Virtex/Spartan-II (manufactured in UMC's 0.22u process) are
the last and fastest device that supports 5V PCI I/O.
Virtex-E/Spartan-IIE (manufactured in UMC's 0.18u process) dropped 5V
PCI I/O support, and it only supports 3V PCI, which is hardly used on
regular desktop motherboards.
I must say that if Virtex-E/Spartan-IIE supported 5V PCI I/O, I rather
have used them instead of Virtex/Spartan-II because newer devices tends
to be cheaper than the older devices of the same density, or for the
same amount of money, you get more gates (and features).
Although not the question you asked, Altera basically did the same thing
when they moved from APEX 20K (supported 5V PCI according to their
datasheet, manufactured in TSMC's 0.22u process) to APEX 20KE (dropped
5V PCI support, manufactured in TSMC's 0.18u process).




Regards,



Kevin Brace (don't respond to me directly, respond within the newsgroup)




Antonio wrote:
> 
> Some hardware question on FPGA :
> 
> 1) What's the difference between a part with speed -3 and another with
> speed -4 , the number is the number of metal layers ??
> 
> 2) I read data sheet of Virtex and Virtex E, I didn't found really
> much difference, can you explain me which is better and why ??
> 
> Thanks

Article: 37822
Subject: Re: You take the low road and I'll ......
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Fri, 21 Dec 2001 12:25:36 +1100
Links: << >>  << T >>  << A >>
"Theory of Complex Conjugates"

Austin Lesea wrote:
> 
> Rick,
> 
> That's It!  Chaos Theory, again!  I knew it all along.  We can predict how many emails
> in any thread it takes to get to the three strange attactor points:  dropped (everyone
> ignores it), VHDL vs verilog, schematic vs hdl, altera vs xilinx, fpga vs asic, ....

Article: 37823
Subject: Re: annoying problem and "simple and clever solution"
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 21 Dec 2001 14:31:06 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Note:
> We did not file a patent,
> did not even write an app note ( mistake! )
> nor a magazine article ( even bigger mistake ).
> 
> It's nice to know that smart guys think alike...
> 
> Meryy Christmas
> Peter Alfke
> =======================================
> Ray Andraka wrote:
> 
> > Heck, I was using that trick with 3000 series parts driving wired ORs
> > back in the early '90s.  The problem was to eliminate the rise time on a
> > shared bus (I think it was a DACK on a motorola processor)

 And the 8051 ports have used this dynamic pullup/Quasi Open Drain,
since 1980,
and the 8048 before that.

Note that the NAND gate OE, will work best with slower devices, and
lightly loaded
BUS loads, and become more marginal on faster devices / more heavy
loads.
 This is because the OE is removed as soon as the IO hits the logic
threshold
( which may not be the same as other connected devices )

It's probably 'good practice' to copy the 80c51 scheme, which uses a
D-FF on the
feedback, so the OE width is clock width, not propogation/threshold
defined.

In a FPGA, D-ff are almost free :-)

- Jim G

Article: 37824
Subject: how to group a critical path into a most small area
From: shengyu_shen@hotmail.com (ssy)
Date: 20 Dec 2001 17:37:41 -0800
Links: << >>  << T >>  << A >>
Hi everyone

I am using APEX20k400E, and my critical path incluse many long route,
so I want to use clique to group the path into a small area so that it
can run more fast.

but when I open Quartus II 1.1's assignment orgnizer, it can only
group the path into a LAB, no other type, but the description tell me
it can group path into a "LAB, row, half row, or the smallest possible
('Best') area",

why?



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