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 25500

Article: 25500
Subject: Re: Code distribution without loss of IP?
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 12 Sep 2000 16:27:02 -0400
Links: << >>  << T >>  << A >>
I believe Xilinx has a intermediate format that is not easy to reverse
engineer. Sort of like object code for C programs. Perhaps other vendors
have the same thing. 

I would not expect a code obfucator to do much for you. It removes the
comments and renames the variables for C files. This certainly would
make a VHDL file harder to modify, but it could still be reversed easier
than an object type file. 

What is your goal? To prevent the multiple reuse by the customer? Or to
prevent modification by the user? 

If you do obfucate the source, how would you support your customer if
they have problems targeting the code?


Johan Petersson wrote:
> 
> Hi Chris,
> 
> Good question, I have been considering it myself. I think there are
> VHDL scramblers around. Let me know if you find one!
> 
> Otherwize I'm planning to get someone to write one for me (rather simple
> script hack using perl i think) - but it'll probably be some time before
> I get that arranged :)
> 
> Good luck,
> Johan :)
> 
> Chris Anderson wrote:
> >
> > Hi,
> > I have a design for a device written using Renoir and ModelSim in VHDL.
> > Initially it's targeted at a Xilinx Virtex. I need to generate an image
> > of this VHDL in a form that is as flexible as VHDL (in terms of the
> > ability to retarget) but is not in a human readable form so that it
> > can't be reverse engineered.
> >
> > Any suggestions?
> >
> > Thanks
> >
> > Chris Anderson

-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 25501
Subject: ABEL trouble with XC95108 and Foundation 2.1i SPVI
From: Hawker <Hawker@connriver.net>
Date: Tue, 12 Sep 2000 17:01:52 -0400
Links: << >>  << T >>  << A >>

Hello;
First time posting here.. Hoping for some help.
I'm new to "doing the guts" of CPLDs and FPGA as I usually just plopped
them on the schematic and someone else did VHDL of the "guts".

Here is my issue:
I have a ABEL block that is a BCD to & segment LCD driver.
It has a phase input (for the LCD) and a Blanking input as well.

It works most of the time just fine but sometimes it sees an input bit as being
inverted from what it really is.
I can make an unrelated change in the schematic and the place of trouble
changes.
Sometimes I also get "impossible" outputs that do not even exist in the ABEL's
valid states.

Could someone please help me with what I could change in this code to be more
stable.

I am using Foundation 2.1i (they have not shipped 3 to me yet) SP VI and
am targeting an XC9500-PC84-15.  Clock speed is 2.048MHZ but I am dividing it
down to 1HZ for most of the design.

Thanx

Rick
(P.s. this is a SPAM avoiding E-mail address . correct address
is my name(see above above)<at>ledinc.com

ABEL script attached below:

module BCD_7Seg
Title 'BCD_7Seg'
"4 BIT BCD TO 7 SEG LCD DRIVER WITH GLOBAL BLANKING and phase

Declarations
"/INPUTS
BCD3..BCD0 	PIN;	"BCD = [BCD3..BCD0];
BLANK		PIN;	"BLANK OUTPUT
PHASE		PIN;	"PHASE MODULATOIN

"/OUTPUTS
Q6..Q0 PIN istype 'com';	" was istype 'reg'
				"Q = [Q6..Q0];

"/NODES
LCD6..LCD0 node istype 'com';	"was 'reg'
PD	   node istype 'com'; "invert PD   LCD = [LCD6..LCD0];

truth_table ( [BCD3..BCD0] -> [LCD6..LCD0] )
                    0      ->  ^B0111111;
                    1      ->  ^B0000110;	
                    2      ->  ^B1011011;
                    3      ->  ^B1001111;
                    4      ->  ^B1100110;
                    5      ->  ^B1101101;
                    6      ->  ^B1111101;
                    7      ->  ^B0000111;
                    8      ->  ^B1111111;
                    9      ->  ^B1101111;
"DASH OUTPUT BELOW AS ALL INVALID
		   10      ->  ^B1000000;
                   11      ->  ^B1000000;
                   12      ->  ^B1000000;
                   13      ->  ^B1000000;
                   14      ->  ^B1000000;
                   15      ->  ^B1000000;


Equations

PD = !PHASE;
Q6 = (LCD6 & !BLANK) !$ PD;
Q5 = (LCD5 & !BLANK) !$ PD;
Q4 = (LCD4 & !BLANK) !$ PD;
Q3 = (LCD3 & !BLANK) !$ PD;
Q2 = (LCD2 & !BLANK) !$ PD;
Q1 = (LCD1 & !BLANK) !$ PD;
Q0 = (LCD0 & !BLANK) !$ PD;


end BCD_7Seg
Article: 25502
Subject: Re: Clock skew in XILINX CPLD
From: tronsmith@my-deja.com
Date: Tue, 12 Sep 2000 22:05:04 GMT
Links: << >>  << T >>  << A >>
Hi Rick,
  (tronsmith is John L. Smith replying via Deja; my company's
news-server didn't catch any of the replies on this thread)

Thanks for your suggestion, no good deed goes unpunished.
Here's some follow-on:

Your response and Thomas' reply leaves me puzzled:
Does "GCLK Optimization: ON"
force signals off of the global routing network?
Or does it keep them on it?
I didn't see any indication of p-term clocks
being used instead of GCLK in the fitting report
for our design.

This doesn't make any sense at all...what kind of
an 'optimization' is it that breaks designs?
(I've seen plenty of optimizations like that, doesn't
make any more sense just for being common) Why would
it be in there to begin with? If the designer has
explicitly entered that he wants a signal on the
global net, one would think the S/W should respect
that.

Assuming this is the culprit, does anyone know
how to turn it off? I've been through and
through the Xilinx Docscan, the only refs to
9500 options are in "Design Manager/Flow Engine
Guide : Implementation Flow Options : XC9500
Implementation Options"; none of those
mention GCLK optimization.
"Use GCLK" is suggested for routing p-term
clock onto GCLK, but nothing is mentioned
about moving a GCLK onto a p-term.
Searching "GCLK optimization" turns up zip.
(I think in general, HITOP has been given
short shrift in the documenation. PAR gets
a whole chapter, but search on HITOP, and
not much comes up)

  Repeating Thomas' original question, does
anyone know how to keep the S/W from breaking
the design? or is there a problem with the
GCLK global routing to begin with?


In article <39BD6297.121188A1@algor.co.uk>,
  Rick Filipkiewicz <rick@algor.co.uk> wrote:
>
> There's just one remote possibility that although you
> have your clock connected
> to a global clock input the
> fitter isn't actually using the global routing. You
> need to check at the fitting
> report to see if there's a line likek
>
> Signall ``fooclk'' mapped onto global clock net GCK<n>
>
> and this at the end
>
> Global (GCLK) optimisation       :ON


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25503
Subject: Re: computing difference between Gray values?
From: "John L. Smith" <jsmith@visicom.com>
Date: Tue, 12 Sep 2000 16:11:34 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------D4355645021A4E410E6ACEDC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


 In many cases, it may not be necessary to mess with Gray code at
all, simply by getting away from the Almost Full(or Empty) flag
mindset that the IDT/Cypress/(pick your favorite FIFO) parts have
left us in (not to mention Peter's app note ;o)).

 For a continuously active fifo moving data from a slower clock
domain to a faster, simply use standard counters. Every
eighth write to the input sets a 'readout request' flag
that is re-sampled (two FF's) in the faster clock domain.
The synch'ed request starts an eight cycle readout sequence.
During the first cycle of that readout, an asynchronous reset is
sent back to the request flag; in the eighth cycle, the synch'ed
request is tested again to see if the fifo has another block
of data. If so, the 8 cycle readout is repeated without a break.

  The circuit is reliable, and supports input clock rates as
close as you care to get to the output clock rate without
going over. I use it as a standard handler for video rate
data, having long ago learned the TOTAL USELESSNESS of
an empty flag for a high-speed fifo whose input clock rate
approaches the output clock rate. ( I emphasize this for
green designers who may have thoughts of using an empty
flag...don't do it, you'll regret it. If you only have
a single cycle to sample an empty flag, you will be burnt
by metastability. Two cycles to sample may save you from
from that, but means you can only support input clock
rates up to 1/3 of the output clock: sample/sample/read/sample/
sample/read/etc.. )

  This burst unload mechanism allows using any sort of
counter you'd like, as long as the burst boundary is
easily detected. The readout request sampling in the
faster clock domain is overlapped with the readout
operation for optimum efficiency.

  What is your application wzjohn? How close and what
speed are your ins and outs?

John

rickman wrote:
> 
> That depends on the rate and timing of data transfer. Although
> oversampling may work for a FIFO count calculation, this is not the same
> thing as clocking the data. The FIFO count will be off by one at any
> given point in time depending on your luck in sampling, without ill
> effect. But the data needs more care to not drop, change or overwrite
> it.
> 
> Ray Andraka wrote:
> >
> > By oversampling the counts for your comparison you are essentially turning the
> > compare into a synchronous system.  I think you still need the gray, at least as
> > you've described it, to avoid sampling a transient state.  It would seem
> > however, that you could have gone to a totally synchronous fifo design with a
> > oversampled rate match register on the slower side to accomplish the same thing.
> >
> > Dan Kuechle wrote:
> > >
> > > using the fast clock, I sampled the two address counters (clk #1),
> > > converted
> > > to binary (clk #2), and did the binary subtraction (clk #3).  Nothing
> > > elegent
> > > here, but it worked, and not too expensive if your address counters are
> > > small.
> > > Now that the design is all working, I question whether I REALLY needed Gray
> > > code address counters in the first place.
> > >
> > > wzjohn@my-deja.com wrote in article <8pkn1p$n8c$1@nnrp1.deja.com>...
> > > > Hi,
> > > > What is the cheapest way to determine the difference between two gray-
> > > > coded values?  My application is a FIFO with different input and output
> > > > clocks.  I would like to know approximately how full the FIFO is at any
> > > > time:  this information is needed in the faster clock domain.
> > > >
> > > > Or am I on the wrong track?
> > > >
> > > > TIA,
> > > >
> > > > wzjohn
--------------D4355645021A4E410E6ACEDC
Content-Type: text/x-vcard; charset=us-ascii;
 name="jsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John L. Smith
Content-Disposition: attachment;
 filename="jsmith.vcf"

begin:vcard 
n:Smith;John L.
tel;work:858-320-4102
x-mozilla-html:FALSE
url:http://www.visicom.com
org:Visicom;Imaging Products
adr:;;10052 Mesa Ridge Court;San Diego;CA;92121;USA
version:2.1
email;internet:jsmith@visicom.com
title:Principal Engineer
x-mozilla-cpt:;30864
fn:John L. Smith
end:vcard

--------------D4355645021A4E410E6ACEDC--

Article: 25504
Subject: Complaint: Xilinx functional simulation libraries
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Tue, 12 Sep 2000 17:27:35 -0700
Links: << >>  << T >>  << A >>
File this under "Why do they do it this way?"

I'm putting together this little chip to average a bunch of samples.  I
have thirty-two sixteen-bit ADC channels.  Each channel is independent. 
I need to average n samples of each channel.  So, I figured I'd
instantiate a bunch of RAM16X1Ds and go, instead of using the CORE
Generator.  So, I did.  Fairly simple to do that sort of thing in VHDL. 
Time to perform functional simulation using the unisim library.

The simulation failed.  Everything was off by one clock tick.  It turns
out that everything in the unisim library has short (100 ps) VITAL
delays, and the rest of my logic is written of course with no delays. 
The test-bench fix was to drive the RAM clock with a slightly-delayed
version of the global clock, but clearly you can't do that if the memory
is four levels down in the hierarchy, and I absolutely hate the idea of
trying to maintain one version of code that's the "simulation" version,
and the other that's the "to-be-implemented" version.

Why do they put any kind of delay mechanism into something that's
supposed to be used for functional simulations?  When I do the logic
design, I'm not concerned about timing!

-- andy
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u
Article: 25505
Subject: Re: Complaint: Xilinx functional simulation libraries
From: korthner@hotmail.nospam.com (K. Orthner)
Date: 13 Sep 2000 01:03:38 GMT
Links: << >>  << T >>  << A >>
I've had exactly the same problem.

This is how I got around it:

In my simulator (Aldec), I made a copy of the library 'unisim', and then 
went through all of it, changing every '0.1ns', '0.01 ns', and so on, to 
'0.0ns'.  (Thank goodness for Search&Replace)

Then I recompiled that into the library  "unisim_nodel". (for No Delay)

n my source code, I include the unisim_nodel library, but I surround it 
with synthesizer directives indicating to ignore the use declaration:

-- SYNOPSYS TRANSLATE_OFF
library UNISIM_NODEL;
use UNISIM_NODEL.all;
-- SYNOPSYS TRANSLATE_ON

When I do my simulation, it uses my timing-crap-free version of the 
library, and when I synthesize, it doesn't see the library and uses real 
components.

Hope this helps.

Note: I currently have a call to Aldec on this about the "officially 
sanctioned" way to do it.

Note2: If you want a copy of my unisim_nodel library, I'll be happy to send 
it.

-Kent

Article: 25506
Subject: Re: VirtexE availability?
From: "Mark Harvey" <mark.harvey@iol.it>
Date: Wed, 13 Sep 2000 03:06:18 GMT
Links: << >>  << T >>  << A >>

rickman <spamgoeshere4@yahoo.com> wrote in message
news:39BA438C.11D2C0CF@yahoo.com...
> Mark,
>
> The relationship between disti and manufacturer is not as well balanced
> and even handed as you might think. The manufacturer often takes
> accounts direct and cuts the disti out entirely. It is all based on
> volume and price pressure. If the volume is high enough and especially
> if the manufacture feels too much pressure to reduce prices, they will
> cut the disti out and pocket the difference themselves. It is seldom
> that the distis get an exclusive sales agreement with the large
> manufacturers.

Hi Rick,

I'm aware of  Xilinx's direct account policy but I was assuming that Andy
isn't a direct account.


> It is also often a *good* idea to speak directly to the manufacturers
> rep as they can give you breaks on pricing that the disti can't, even if
> you are ultimately buying through the disti. Of course this only works
> if you are buying thousands of units. But even at 1000 pieces I have
> gotten better pricing than what the disti would quote me.


mmm....not so sure about this one, the disti is free to add his own margin
but I still don't think
the rep should be able to undercut him


>
>
> Mark Harvey wrote:
> >
> > S. Ramirez <sramirez@deleet.cfl.rr.com> wrote in message
> > news:Judu5.13363$98.1346052@typhoon.tampabay.rr.com...
> > > Andy,
> > >      Earlier, I posted a message to the newsgroup that explained how
the
> > > disties work and what their motivations are.  A large amount of their
time
> > > is spent "registering" parts.
> >
> > Because that's the only way that they get lower pricing from Xilinx -
it's
> > what
> > Xilinx want them to do.
> >
> > >      You are correct in saying that they will jump all over you asking
> > those
> > > silly questions, because they are trying to build a case for
registering
> > the
> > > design socket with, of all people, the Xilinx manufacturer's rep
(Xilinx
> > > rep)!
> > >      What you should do is get in touch with the Xilinx rep yourself.
> > This
> > > is the person that the disty will go to to get availability and price
> > > information, so why not go there yourself?  With Virtex-E parts,
> > > availability and other information are scarce, and the disties are
forced
> > to
> > > go to the Xilinx rep for the answers.
> > >Tell the rep that you do not want any
> > > disties in on your design.  Explain to him/her that you are not
interested
> > > in a bunch of people bothering you "on this one."  They will keep the
> > > information to themselves and not involve the disties.
> >
> > If the rep in my area did this, the disties run would screaming to
Xilinx,
> > no rep should ever do this, after all the rep can't sell the parts, only
the
> > disties.
> >
> > >      The exception to the above is if you need parts that are well
> > > established.  In this case, the disties may have parts on their
shelves.
> > If
> > > they do, great, but if they don't, they will have to go to the rep
again.
> >
> > Why, he certainly doesn't have any on HIS shelf!
> >
> > > In either case, you will have the salesperson or the FAE knocking on
your
> > > door or calling you up for the same reason -- to gather information in
> > order
> > > to register the part.
> > >     So my advice is, if you don't want the disties to come give you a
2
> > hour
> > > PowerPoint presentation on why they are the chosen ones, to call the
> > Xilinx
> > > rep yourself regardless of the part.  Let the rep find the parts for
you
> > at
> > > the disty warehouse or factory.
> >
> > What's the point of asking the rep to ask the disty? ..and if the rep
sells
> > direct from factory, the disty should immediately complain to Xilinx.
> >
> >   That way you will minimize disty PowerPoint
> > > presentations and obnoxious questions.
> >
> > Better just to tell the disty to leave his powerpoint slides at home.
> >
> > At the end of the day, all Xilinx devices sold thru the disties must
> > undergo the design registration process, it's better to build a
> > relationship with a disty that you trust, who gives good tech support &
> > service and let
> > him/her register all your designs - that way he/she is guaranteed lower
> > pricing from the rep & has further incentive to keep giving you support.
> >
> > Use the design registration as a carrot on a stick to wave in front of
the
> > disty.....no support, no registration.
> >
> > >      By the way, this is true of most semiconductor companies, not
just
> > > Xilinx.
> > > -Simon Ramirez, Consultant
> > >  Synchronous Design, Inc.
> > >
> > >
> > >
> > > "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message
> > > news:8pbfj5$16qm$1@noao.edu...
> > > > I really hate to ask silly questions like this, but I hate calling
the
> > > > distros because once you tell them you're thinking about considering
> > > > thinking about using a part in a design, they jump all over you
because
> > > > they think you're gonna be writing a req for 10,000 parts tomorrow
...
> > > >
> > > > I'm looking at doing a VirtexE design.  XCV50E should be big enough.
> > > > Mainly, I want the LVDS I/O.  Are they available now, or will they
be
> > > > available in the next couple of months?
> > > >
> > > > Of course, I could probably do the design with external LVDS parts,
but
> > > > this seems like a "neat" solution.
> > > >
> > > > -- andy
> > > > ----------------------------
> > > > Andy Peters
> > > > Sr. Electrical Engineer
> > > > National Optical Astronomy Observatory
> > > > 950 N Cherry Ave
> > > > Tucson, AZ 85719
> > > > apeters (at) n o a o [dot] e d u
> > > >
> > >
> > >
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
>
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com


Article: 25507
Subject: Re: VirtexE availability?
From: "Mark Harvey" <mark.harvey@iol.it>
Date: Wed, 13 Sep 2000 03:15:48 GMT
Links: << >>  << T >>  << A >>

S. Ramirez <sramirez@deleet.cfl.rr.com> wrote in message
news:foCu5.18606$98.2061199@typhoon.tampabay.rr.com...
> > Because that's the only way that they get lower pricing from Xilinx -
it's
> > what Xilinx want them to do.
>
> --This is true.  The design registration process guarantees that Xilinx
will
> sell to the disty owning the registration at a lower price, thus allowing
> that particular disty to undercut the other disties and get the sale
(unless
> the buyer is playing games).
>
> > If the rep in my area did this, the disties run would screaming to
Xilinx,
> > no rep should ever do this, after all the rep can't sell the parts, only
> the
> > disties.
>
> --The rep in your area has no balls.  If the rep has reason(s) to withhold
> information from the disties, then (s)he should do it, unless of course
> (s)he is YOUR rep.

The rep in my area certainly doesn't lack any balls!


My reps have always honored my requests to withhold
> information.  I give them reasons to, and they do it.  I've seen disties
run
> to the rep screaming, after the design cycle is over, that they helped me
> throughout the design process, and that without them, I couldn't have
pulled
> it off.  The rep(s) have all seen this before, knowing that sometimes the
> disties claim they did a lot of support work when in fact they didn't.

that's a different story, if the disti is being dishonest, then sure, go
ahead and tell
the rep and/or Xilinx.

 In
> the final analysis, it all boils down to money.  The disties want to make
> money on every deal, support or no support.

Err. yes, like most corporations in this world they exist to make money for
the stockholders and employees - don't see any problem with that.

>  The reps will always jump at a chance to make MORE money if you give them
a good enough reason.

Just like the disti ;)

 > Andy's request to keep the disties out of the picture so that he doesn't
get
> bothered by them would be honored by my reps.
>
> > What's the point of asking the rep to ask the disty? ..and if the rep
> sells
> > direct from factory, the disty should immediately complain to Xilinx.
>
> --I've seen disties complain and lose.  Xilinx wants to make money and
> sometimes that takes disty involvement.  However, if the disties did not
> help me one bit or one byte, and the local Xilinx rep can make more money
if
> (s)he leaves the disties out of the picture, I guarantee you again that
the
> disties will lose.


>  The disties basic recourse is to escalate the matter
> above the local rep, and they better have a damn good story.  But from my
> experience, all it takes is the higher authority making a few phone calls
to
> find out the several perpectives, including mine!  The final result may be
> losing this particular sale and possible future ones, since they P.O.ed
the
> rep.

Again, if the disti has been dishonest or exaggerated his/her tech support,
then they deserve to be put in their place.

>
> > Better just to tell the disty to leave his powerpoint slides at home.
>
> --Some disties can't talk to engineers without a PowerPoint presentation.
> They just aren't technical enough to pull it off.  Just start asking hard
> questions, and they'll say "I'll get back to you on that."
>
> > Use the design registration as a carrot on a stick to wave in front of
the
> > disty.....no support, no registration.
>
> --I agree with you here 100%.  I bet that if Andy, the original poster,
had
> a darn good Xilinx specific disty FAE, he wouldn't have the problem he is
> having.  His problem (my opinion) is that the disties are asking him a lot
> of questions, contributing nothing to his cause, wasting his time, and
they
> are still getting the registration!

But somebody, somewhere HAS to register the design.

>  Therefore, what they're doing works for
> them.
>
> -Simon Ramirez, Consultant
>  Synchronous Design, Inc.
>
>


Article: 25508
Subject: Re: VirtexE availability?
From: "Mark Harvey" <mark.harvey@iol.it>
Date: Wed, 13 Sep 2000 03:22:18 GMT
Links: << >>  << T >>  << A >>

S. Ramirez <sramirez@deleet.cfl.rr.com> wrote in message
news:YA9v5.40366$58.5311575@typhoon.tampabay.rr.com...
.
> --If you are browsing through the Xilinx web site, and that action caused
a
> distributor to call you, then this means that the Xilinx rep turned him on
> to you.  It is the rep that gets this "report" from Xilinx.  The fact that
> the disty called you tells me something -- the rep and one of the disties
> are very tight with each other.  Is it only one disty that seems to be
> favored this way?
>
>

When you register for WebPack, you are asked to specify a preferred disti
(or indicate no preference) - the "lead" will be passed on to that disti.





Article: 25509
Subject: Re: hardware compatibility and patent infringement
From: "Martin Usher" <martinusher@earthlink.net>
Date: Wed, 13 Sep 2000 03:33:52 GMT
Links: << >>  << T >>  << A >>
>
> This is not correct...  At least not according to MIPS's lawyers.  MIPS is
> currently suing Lexra for doing software emulation of some patented
> instructions (LWL, LWR, SWL, and SWR to be exact).  Of course
> Lexra's lawyers would disagree.
>
1) What do these instructions do? (They look like 'word shift' type
operations....)

2) Did they patent the instruction menomic or what the instruction did? If
its the latter then a patent has been issued for an algorithm. I do hope its
not a commonly employed one - I can't think of any operations at the
register level that haven't been implemented in some machine or another over
the last five decades.

2a) Then there's the issue of instruction emulation by microcode. This
sounds fancy and modern but the technique has been around for decades - its
the logical way to implement complex instructions on a processor. Emulating
other people's instructions isn't new. I first became aware of a machine
that could do this in the mid 70s - it was offered as a way of running
software from a new range of computers and the company's legacy systems.

2b) I think everyone agrees that the patent office needs reinventing. It
currently does more damage than good in our business, IMHO.

3) Intel didn't patent their instruction set. They copyrighted it. That's
why NEC had to come up with creative alternative names for the same
instructions in their 'V' series. AMD and the like were OK due to some
second sourcing agreement.

4) I've got a real 'thing' about people who patent bullshit things,
especially if they really believe that they invented this stuff. It takes a
special combination of arrogance and ignorance to believe that you have
truly invented something basic in our trade. They need to humble up, learn a
bit, and maybe work hard enough to actually invent something new.


Article: 25510
Subject: Re: hardware compatibility and patent infringement
From: Bill Pringlemeir <bpringlemeir@yahoo.com>
Date: Wed, 13 Sep 2000 04:53:19 GMT
Links: << >>  << T >>  << A >>
>>>>> "Martin" == Martin Usher <martinusher@earthlink.net> writes:

[snip]

 Martin> 4) I've got a real 'thing' about people who patent bullshit
 Martin> things, especially if they really believe that they invented
 Martin> this stuff. It takes a special combination of arrogance and
 Martin> ignorance to believe that you have truly invented something
 Martin> basic in our trade. They need to humble up, learn a bit, and
 Martin> maybe work hard enough to actually invent something new.

[facetiousness on]

I have a patent pending on the use of the * character in `C' code.
And may I say I am brilliant for deciding to finally use this
character that is defined in the `C' standard, IMHO. This explains why
C++ has a novel use of the "&" character.  Please switch now or be
sued.

[facetiousness off]

Bill

Article: 25511
Subject: Re: Complaint: Xilinx functional simulation libraries
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Wed, 13 Sep 2000 05:53:37 GMT
Links: << >>  << T >>  << A >>
Andy and others,

How about recompling UniSims with the RAM's "timing checks on" generic set
to false?  This is what I've been doing since last year, and so far it's
been working fine.  (At one point I concerned stuff like the IEEE libraries
and UniSims to be sacred and untouchable.  No more; these days I routinely
recompile them all...)

I find it incredible that timing checks in UniSim are ON by default, but
displaying error messages is OFF by default (with timing checks on, in
functional simulation, you'll get error messages all over for 0ns holds) .
Bizarre.

---Joel Kolstad



Article: 25512
Subject: Re: Complaint: Xilinx functional simulation libraries
From: korthner@hotmail.nospam.com (K. Orthner)
Date: 13 Sep 2000 06:42:53 GMT
Links: << >>  << T >>  << A >>
Joel, I'm not sure about this, but won't turning off the "timing checks on" 
generic only disable the timing checks?  What it won't do is prevent the 
instantiated components from having delays.

Or am I mistaken here?


>I find it incredible that timing checks in UniSim are ON by default, but
>displaying error messages is OFF by default (with timing checks on, in
>functional simulation, you'll get error messages all over for 0ns holds)

That's something else I found odd.
Using Xilinx tools, you get errors for 0ns holds, but looking in the data 
sheet, 0ns holds are *okay*.

<shrug>

-kent


Article: 25513
Subject: Re: flipflops/statemachine/fifos and timing
From: Richard Meester <rme@quest-innovations.com>
Date: Wed, 13 Sep 2000 08:44:12 +0200
Links: << >>  << T >>  << A >>
Rick,

Thanks this is excactly what i mean, so now i am sure.

Richard

rickman wrote:

> I think I understand your question. You are not sure which positive edge
> of the clock registers the data, S2 or S3. The problem is that the
> simulator does not show any delay (other than perhaps the minimum timing
> resolution) and makes the outputs of the FFs look like they change at
> the same time as the clock edge. Really they are slightly delayed.
>
> Let me draw a picture that is how the signals really are.
>
>          |  S1   |  S2   |  S3  |
>           ___     ___     ___
> CLK   ___|   |___|   |___|   |___
>       ____  ______  ______  _____
> Data  ____><__1___><__2___><_____
>       ____  ______  ______  _____
> FIFO  ____><______><______><__2__
>       _____________         _____
> WREN               \_______/
>
> Here it shows that the data from the RAM changes just after the rising
> edge of the clock. So the data that is latched into the FIFO is the data
> that was stable before the clock edge and not the new data that comes
> *after* the clock edge.
>
> Is that more clear?
>
> Richard Meester wrote:
> >
> > Hi all,
> >
> > i have a general question regarding some timing issues. I am doing a
> > project connecting an fpga to an extern synchronous dpram. This dpram
> > has 1 cycle delay in pipelined operation.
> >
> > the problem i am having has to do with timing and enabling of flipflops
> > etc.
> > Currently i have a state diagram as follows.
> > s1 : output address on bus.
> > s2 : enable writeenable of internal fifo.
> > s3: -- at this point the data is clocked in from the external address
> > bus into the internal fifo.
> >
> > When i do a functional simulation i see indeed that the enable of the
> > internal fifo goes high at state2 (excactly at the positife clock edge).
> > But does it now start clocking in the data at this point, or on the next
> > clock cycle (and thus the time when we are in state 3.) In simulation is
> > see that at the clock pulse of S2 the enable goes high, but i don't know
> > if the data is now clocked in or not. I presume that the data is clocked
> > in on the next clock cycle, since the enable signal is set in state 2,
> > and state 2 is relative to a pos_edge clock, and thus at the rising edge
> > of the clock the wr_enable line was not high, and thus the data should
> > not be clocked in at S2, but at the next cycle.
> >
> > Thanks in advance,
> >
> > Richard
> >
> > --
> > Quest Innovations
> > tel: +31 (0) 227 604046
> > http://www.quest-innovations.com
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com

--
Quest Innovations
tel: +31 (0) 227 604046
http://www.quest-innovations.com


Article: 25514
Subject: Re: Complaint: Xilinx functional simulation libraries
From: Ray Andraka <ray@andraka.com>
Date: Wed, 13 Sep 2000 06:45:38 GMT
Links: << >>  << T >>  << A >>
I also ran into the same thing.  When you instantiate the clocked unisim
components, set the TimingChecksOn generic to "FALSE" to disable the timing
crap.  You'll also have to surround the generic in the declaration with
syn_translate on and off pragmas to keep the synthesis from complaining.  For
example:

component FDCE
  --synthesis translate off
  generic(TimingChecksOn: Boolean := FALSE);
  --synthesis translate on
port (D,C,CE,CLR : in std_logic;
   Q : out std_logic);
end component;
attribute syn_black_box of FDCE:component is true;


"K. Orthner" wrote:
> 
> I've had exactly the same problem.
> 
> This is how I got around it:
> 
> In my simulator (Aldec), I made a copy of the library 'unisim', and then
> went through all of it, changing every '0.1ns', '0.01 ns', and so on, to
> '0.0ns'.  (Thank goodness for Search&Replace)
> 
> Then I recompiled that into the library  "unisim_nodel". (for No Delay)
> 
> n my source code, I include the unisim_nodel library, but I surround it
> with synthesizer directives indicating to ignore the use declaration:
> 
> -- SYNOPSYS TRANSLATE_OFF
> library UNISIM_NODEL;
> use UNISIM_NODEL.all;
> -- SYNOPSYS TRANSLATE_ON
> 
> When I do my simulation, it uses my timing-crap-free version of the
> library, and when I synthesize, it doesn't see the library and uses real
> components.
> 
> Hope this helps.
> 
> Note: I currently have a call to Aldec on this about the "officially
> sanctioned" way to do it.
> 
> Note2: If you want a copy of my unisim_nodel library, I'll be happy to send
> it.
> 
> -Kent

-- 
-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  or http://www.fpga-guru.com
Article: 25515
Subject: Re: flipflops/statemachine/fifos and timing
From: Richard Meester <rme@quest-innovations.com>
Date: Wed, 13 Sep 2000 08:46:40 +0200
Links: << >>  << T >>  << A >>
Johan,

Johan Petersson wrote:

> Hi Richard,
>
> Why don't you try and synthesize your design, do a preliminary backend
> implementation
> in your favourite architecture and finally generate a back annotated
> vhdl-netlist?
>
> That should be feasible in any gate array with any normal tools these
> days.
>
> If you are working with Xilinx fpga's i could send you a makefile that
> shows,
> among other things, how the back annotated netlist is generated.
>
> Good luck,
> Johan :)
>
> ps It will be very difficult for anyone to give you a good answer to
> your
> question unless you include the source code for your state-machine and a
> detailed
> timing diagram of your memories. Further - I guess you would like to
> have some
> kind of information about the pcb/pcbs that you will put your stuff on.
>

What kind of info about the pcb/pcbs. I lokated the dpram close to the fpga as
possible, so there should be no problem there. and the rest is straight
forward (i think).

Richard


>
> Is your fifo in the FPGA by the way? To answer your fifo question i
> would have
> to know something more about the fifo as well...
>
> Richard Meester wrote:
> >
> > Hi all,
> >
> > i have a general question regarding some timing issues. I am doing a
> > project connecting an fpga to an extern synchronous dpram. This dpram
> > has 1 cycle delay in pipelined operation.
> >
> > the problem i am having has to do with timing and enabling of flipflops
> > etc.
> > Currently i have a state diagram as follows.
> > s1 : output address on bus.
> > s2 : enable writeenable of internal fifo.
> > s3: -- at this point the data is clocked in from the external address
> > bus into the internal fifo.
> >
> > When i do a functional simulation i see indeed that the enable of the
> > internal fifo goes high at state2 (excactly at the positife clock edge).
> > But does it now start clocking in the data at this point, or on the next
> > clock cycle (and thus the time when we are in state 3.) In simulation is
> > see that at the clock pulse of S2 the enable goes high, but i don't know
> > if the data is now clocked in or not. I presume that the data is clocked
> > in on the next clock cycle, since the enable signal is set in state 2,
> > and state 2 is relative to a pos_edge clock, and thus at the rising edge
> > of the clock the wr_enable line was not high, and thus the data should
> > not be clocked in at S2, but at the next cycle.
> >
> > Thanks in advance,
> >
> > Richard
> >
> > --
> > Quest Innovations
> > tel: +31 (0) 227 604046
> > http://www.quest-innovations.com
>
> --
> APZ FOR MEN BECAUSE FIRST IMPRESSIONS LASTS

--
Quest Innovations
tel: +31 (0) 227 604046
http://www.quest-innovations.com


Article: 25516
Subject: Re: Complaint: Xilinx functional simulation libraries
From: Tobias Stumber <Tobias.Stumber@de.bosch.com>
Date: Wed, 13 Sep 2000 09:10:52 +0200
Links: << >>  << T >>  << A >>

"K. Orthner" <korthner@hotmail.nospam.com> schrieb im Newsbeitrag
news:8FAEA273Dkorthnerhotmailcom@158.202.232.7...

> That's something else I found odd.
> Using Xilinx tools, you get errors for 0ns holds, but looking in the data
> sheet, 0ns holds are *okay*.

Look at the Xilinx note " How can hold time violations
occur when the data book states 0 ns hold times? " at
http://support.xilinx.com/techdocs/782.htm
for this question.

If you use the ModelSim you can turn the switch "disable
vital timing checks" on and the simulation runs without
setup/hold error messages and all the 'X's in the RAMs
are gone (was gone in my simulation).

Tobias




Article: 25517
Subject: Re: Complaint: Xilinx functional simulation libraries
From: korthner@hotmail.nospam.com (K. Orthner)
Date: 13 Sep 2000 07:12:21 GMT
Links: << >>  << T >>  << A >>
Ray,

You mean I didn't have to go recompile the unisim libraries?  It's as easy 
as setting the generic to FALSE?  Then all the nasty timing ptoblems go 
away?


ray@andraka.com (Ray Andraka) wrote in <39BF2224.8921F01@andraka.com>:

>I also ran into the same thing.  When you instantiate the clocked unisim
>components, set the TimingChecksOn generic to "FALSE" to disable the
>timing crap.  You'll also have to surround the generic in the
>declaration with syn_translate on and off pragmas to keep the synthesis
>from complaining.  For example:


Article: 25518
Subject: Re: Clock skew in XILINX CPLD
From: falk@iee.et.tu-dresden.de (Thomas Falk )
Date: 13 Sep 2000 07:22:06 GMT
Links: << >>  << T >>  << A >>
Hi Simon,

thanks for your answer. In my case the parallel input works fortunately,
but some of the logik detecting slopes in slow impulse trains does fail.

Interestingly enough, there seems to be a lot of experiences in this
group with similar problems, but I haven't heard anything from XILINX yet.

Thanks,

Thomas

PS: Simon, despite your experiences with synchronizers you call your
company still Synchronous Design ?   ;-)

Article: 25519
Subject: Re: Complaint: Xilinx functional simulation libraries
From: korthner@hotmail.nospam.com (K. Orthner)
Date: 13 Sep 2000 08:17:44 GMT
Links: << >>  << T >>  << A >>
That clarifies it a lot for me, Tobias.

Thanks!


Tobias.Stumber@de.bosch.com (Tobias Stumber) wrote in
>Look at the Xilinx note " How can hold time violations
>occur when the data book states 0 ns hold times? " at
>http://support.xilinx.com/techdocs/782.htm
>for this question.

Article: 25520
Subject: Re: Accessing internal signals and ports for writing to a file using testbench
From: abica@my-deja.com
Date: Wed, 13 Sep 2000 08:52:00 GMT
Links: << >>  << T >>  << A >>
In article <0bvv5.256972$1h3.4986622@news20.bellglobal.com>,
  "Nestor" <nestor@ece.concordia.ca> wrote:
> Thanks to everyone for the replies.  The declaration of a package
with probe
> signals seems to be good enough for my purposes.  I will need to try
it out,
> most likely tomorrow.
>
> Nestor
>

If you use Modelsim, the simplest way is to view the signal in a list
(using strobe option with the period you want), then save the list as
TSSI. You will have a text file with values written on a column.

Adrian


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25521
Subject: Re: virtex shape
From: "Bill Blyth" <bb@alphadata.co.uk>
Date: Wed, 13 Sep 2000 09:59:27 +0100
Links: << >>  << T >>  << A >>
Are you lot talking about the logical shape or the physical shape?

 From what I've seen looking at the encapsulation, the real device is square
and this would makes sense as the package is also square.

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:39BE904A.9CEC66A2@yahoo.com...
> I think he is asking why the rows and columns are not the same count in
> contrast to many of the other Xilinx families. I don't know that anyone
> would care that the die itself is not square. In fact many memory chips
> are made rectangular just so they will fit in the packages.
>
> I can't say why Xilinx chose non square arrangements of the CLBs. Some
> of their chips are square and some aren't. Maybe the CLBs are not square
> and they adjust the rows and columns to make the die square???  ;)
>
>
> Johan Petersson wrote:
> >
> > Hmm,
> >
> > No idea, but it isn't the only non square chip around. Not that I'm an
> > expert
> > on chip squareness :) I think the terrible hole-mounted 5000 pld's from
> > Altera
> > were squre, and some memory chips are square, aren't they??
> >
> > Maybe it's a question of bonding the signals out from the chip to the
> > pins - or
> > maybe internal routing efficiency...
> >
> > Who knows,
> > Tell me if you get the answer somehow!
> >
> > --JOHAN :)
> >
> > erika_uk@my-deja.com wrote:
> > >
> > > hey,
> > >
> > > why virtex chips are rectangular and not square
> > >
> > > --ERIKA
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
>
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com


Article: 25522
Subject: Re: Clock skew in XILINX CPLD
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 13 Sep 2000 21:33:31 +1200
Links: << >>  << T >>  << A >>
Thomas Falk wrote:
> 
> Hi Simon,
> 
> thanks for your answer. In my case the parallel input works fortunately,
> but some of the logik detecting slopes in slow impulse trains does fail.

Can you clarify 'slopes in slow inpulse trains' - are these slow edges,
and how many registers do they feed ?

-jg
Article: 25523
Subject: Re: Is this practical?
From: Michael Warner <mvw@ozemail.com.au>
Date: Wed, 13 Sep 2000 19:33:11 +0930
Links: << >>  << T >>  << A >>
On Tue, 12 Sep 2000 12:39:54 GMT, kolja@prowokulta.org wrote:

>For many applications where a PWM is used a Delta-Sigma DAC gets even
>better results. There is a Xilinx applications note XAPP154 on how to do
>a 8-Bit S-D DAC in 10 LUTs plus 17 Registers => 9 Slices
>This would result in 567+epsilon Slices and would fit in a XC2S50.

This isn't for high-resolution D/A work (which is lucky, since your
notes go right over my head! :-)

>If all the PWMs are synchronous (They use the same PWM cycle)
>one counter and 64 comparators with 8-Bit input register and
>one bit output register should be sufficient.

Yes, they are, and that approach did occur to me. Would it be simpler
than 64 simple ripple counters?

>This would reduce the hardware cost to one LUT per Bit or 5 Slices per
>channel or 320+epsilon Slices total. (A loose fit in a XC2S30)

Thanks for the advice!
Article: 25524
Subject: Re: Is this practical?
From: Michael Warner <mvw@ozemail.com.au>
Date: Wed, 13 Sep 2000 19:37:57 +0930
Links: << >>  << T >>  << A >>
On Tue, 12 Sep 2000 11:59:31 GMT, Ray Andraka <ray@andraka.com> wrote:

>what is the available clock and required sample rate?  If you can supply a
>multiplied clock, you can reduce the size of the logic substantially.

It's pretty slow - the PWM time-slice is probably no less than 1us.
I'll have to read up on these "multiplied clocks", since they seem to
be the key to success :-)

Thanks for your help, folks!


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