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 43950

Article: 43950
Subject: Re: Spartan II Proto. Board
From: spam_hater_7@email.com (Spam Hater)
Date: Fri, 07 Jun 2002 06:06:08 GMT
Links: << >>  << T >>  << A >>

Is that a Spartan-II or a SpartanXL board your selling?

Yes, that's a real EMail address.


On Thu, 6 Jun 2002 03:36:43 -0400, "Dan"
<daniel.deconinck@sympatico.ca> wrote:

>Hi Greg,
>
>You can program the Insight SpartanII with X-Checker or MultiLinx.
>
>My board is for sale for 50% off. Are you interested ?
>
>Sincerely
>Daniel DeConinck
>www.PixelSmart.com
>TEL: 416-248-4473
>
>
>


Article: 43951
Subject: Re: Scientific puzzle of formal circuit verification at next week's DAC
From: Kelly Hall <hall@priest.com>
Date: Fri, 07 Jun 2002 06:32:59 GMT
Links: << >>  << T >>  << A >>
On 7 Jun 2002 05:17:05 GMT, Steve Meyer <sjmeyer@www.tdl.com> wrote:
> This may be a side effect of commercialization of Computer Science,
> but there is a very interesting scientific puzzle that one can observe
> at next week's Design Automation Conference (DAC).  Namely, that although
> formal verification has been a degenerating research program since at
> least 1972, nearly every technical paper and new exhibitor is describing
> tools for formal verification of circuits.

Define 'degenerating' because I have no idea what you're trying to say.
Please - I'm genuinely puzzled by what you said.  I know a few people
making their living quite nicely doing formal methods in academia, 
government, and industry.  What part of FM is degenerating?
 
> These tools supposedly lead to RTL sign off without a need to simulate and
> verification usally by software checking of user supplied constraints.

I've never heard *any* formal methods person advocate not simulating the
RTL.  Maybe I've not travelled in the same circles you have.  All you get
from FM is confidence that two representations of your circuit (your spec
and your implementation) have some relationship (equivalency, implication).
That certainly doesn't prevent your synthesis tool from breaking your 
design, or your layout tool, or the fab house.  

I like simulating the RTL as much to have confidence in my formal specs 
as to gain trust in my design.

> Here are Some of the puzzles.  1) because formal proving is related to
> BDD construction from net lists, this formal analysis should be usable
> in communication code breaking cryptography.  Yet, paper at this year's
> Eurocrypt showed heuristics for the related NP complete problem do not help.
> Reference is: Krause, M. "BDD-based Cryptanalysis of Keystream Generators",
> Proceeding 2002 Eurocrypt, Springer, 2002.  Also the objections to
> formal verification first detailed in the Lighthill Report submitted to
> the British Government in 1972 still need answers.  

I think you need to get out and look at formal methods more.  I'm from the
theorem prover side of the house (as opposed to the BDD side) and it's not
a problem to omit BDDs entirely if you don't mind algebraic representations.  

I haven't read the paper you've cited, but I gave a lot of thought to
crypto applications when I was in grad school.  Feel free to ignore this:

As to why BDDs aren't much use for crypto, the answer isn't hard: BDDs only
have huge gains when the logic functions collapse nicely under a certain
ordering of the logic variables.  A big random function of 128 variables
probably won't become tractable just because you throw BDDs at it.  Luckily,
most of the sorts of functions that real-life hardware designers use are 
much more amenable to BDDs, given a suitable variable ordering.  Crypto
functions are generally designed to mix up the variables quite completely,
making the functions hard to manipulate algebraically (via theorem provers)
or via BDDs.  

As to the 1972 paper, I'd have to go find it.  The earliest FM-for-hardware
papers I've studied are the RSRE Viper project from the mid 1980s.  Is the
Lighthill Report online?

> Some are: 1) how is
> correctness of human coded assertions verified, i.e. errors in assertions
> become injected into formally verified circuits?,

The problem of writing 'correct' specifications is, IMHO, harder than the
problem of showing that a given design meets the specification.  Joe 
Jackson said is succintly: you can't get what you want 'till you know
what you want.  The best ways I've found for writing good specs is lots
of peer review together with use-case analysis; simulators also help a
lot.  Wwriting specs for hardware isn't much different than writing specs
for software.  Excepting those damn-near unreadable temporal logic specs,
of course.  Those are the specification equivalent to apl - write only.

> 2) how can circuit proving
> data structures not have exponential size?

Here are two ideas: a) BDDs may reduce ugly logic equations to a more
compact form, under certain ordering of the variables.  See McMillan's
"Symbolic Model Checking", or any BDD reference.  I say 'may' because 
there are worst-case functions that are not amenable to BDDs.  Fortunately, 
those sorts of functions are rare in most hardware designs, although crypto 
hardware is a notable exception. b) if you maintain the function 
symbolically, and do your verification that way, you may avoid exponential 
size at the expense of doing a big proof instead.  If you do a brute-force 
case-analysis on the variables, of course you'll get an exponential number
of proof cases.  But the power of the proof tools is being able to perform 
induction or otherwise make the proof tractible.

> 3) how can verification work
> when the same formal algorithms are used to synthesize circuit in one
> direction and verify them in other direction using same "closed system"
> algorithms.

I think you're confused here.  Every formal verification tool I've seen
attempts to show equivalence (or at least implication) of two different
formalisms.  For example, between a formal specification written in some
logic (be it a temporal logic, or higher-order logic, or even propositional
logic) and an implementation represented as a state machine, or BDDs, or
some other representation.  The benefit lies in showing that the
implementation satisfies the spec.

The equivalence checking folks make their money (or used to, anyway)
by showing the equivalence of two diffenent forms of the implementation,
as when the design is revved for other bug fixing.  The formal checking
takes less time than running a complete regression simulation, hopefully.

> It is unfortunate that DAC technical committee does not try to balance
> papers that advocate theories with papers that falsify theories.

No one declared DAC the end-all and be-all of formal methods.
If you've got some interesting results to present to the world, you've
already found Usenet.  Matt Drudge broke the Monica Lewinsky fiasco on
his web site - I would assume that you could create a web page on which
to publish your results.

If you're just bent because DAC rejected your paper, get over it.  The
papers of many people are rejected from DAC - they've got finite space
and time considerations.  You're actually in good company.

> In any
> case, what is probably the most one side scientific refereeing in the last
> 500 years should make for interesting listening and observing.

I think you *might* be over-reacting just a smidge to having your paper
rejected.  500 years of history goes back to 1502.  Do you really believe
DAC 2002 is the most one-sided scientific event in all that time?

So what's the kernel of your gripe with formal methods?  It sounds like
you're convinced that FM is totally bogus.  I think it's merely a pain
in the butt, expensive, and arcane.  But with ICs having 50M transitors
and development schedules under 12 months, FM starts making sense compared
to the concept of thousands of workstations running simulations 24/7.

Kelly

Article: 43952
Subject: Re: Quartus v/s Leonardo
From: "Paul Baxter" <pauljnospambaxter@hotnospammail.com>
Date: Fri, 7 Jun 2002 08:53:44 +0100
Links: << >>  << T >>  << A >>
> Since LS-Altera is free (Albeit the GUI is buggy.) even for QII Web
> Edition users (Although I rather get a free crippled ModelSim instead.),
> there really is no reason to use Quartus II native synthesis tool at all
> other than maybe some beginners may appreciate it because they won't
> have to import an EDIF netlist from LS-Altera.

I echo the sentiment NOT to use quartus for synthesis, just place and route
with the edif output from leonardo.
If you use the buggy (but useable) gui you can even do the quartus place and
route from within Leo.

I would however use Q2 to generate PAR constraints as you can get more
detailed than using Leo alone.

I'm still using Leo 2001_1d, anyone any comments on the newest release?




Article: 43953
Subject: Re: Do I have metastability issues?
From: "Ken Mac" <aeu96186@yahoo.co.uk>
Date: Fri, 7 Jun 2002 08:54:50 +0100
Links: << >>  << T >>  << A >>

John,

I think I have enough info now!

I will try it out when I come to implement in a couple of weeks...

Thanks for your detailed help,

Ken

"John_H" <johnhandwork@mail.com> wrote in message
news:3CFF8535.C8507535@mail.com...
> If you're generating both clocks, the absolute best way is to run the
whole
> design at 100MHz and only clock in the 25 MHz every fourth clock.  No
CLKDLL
> needed!
>
> always @(posedge clk100)
> begin
>   // 1-of-4 pulse generator gives clean clkEna pulses
>   Gate25[3:0] <= |Gate25[2:0] ? Gate25 <<1 : 4'h1;
>   // The ena can be synthesized into logic or into the ena pin on and FDE
>   if( Gate25[3] ) Data25MHz <= Data25MHzIn;
> end
>
> If the 25MHz section wants 40ns for the logic rather than 10ns as
suggested by
> the 100MHz clock, you can apply multi-cycle path timing consstraints to
allow
> the full 40ns cycle for the Xilinx place and route.
>
>
>
> Otherwise, if your direction is only 25MHz to 100MHz domain, choosing the
270
> phase for your 100MHz clock will give you 7.5 ns for the transition
between the
> two domains.  If you go back to the 25MHz domain this would result in only
2.5
> ns suggesting a 180 clock for 5ns on each side might be better.
>
> I think the DLLs like the 0 phase feedback.
>



Article: 43954
Subject: Quick newbie question...
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Fri, 7 Jun 2002 10:17:28 +0200
Links: << >>  << T >>  << A >>
Hi,

This is a easy newbie question (I'm asking this as, up until now, I have
just been concerned with designing and not programming!).

Anyway, am using a Spartan II and will use an XC18V02 PROM. When I power-up,
does the PROM begin to program the FPGA immediately after the power levels
are stable?

adrian




Article: 43955
Subject: Re: PowerPC Architecture
From: Vladislav Vasilenko <vlad@comsys.ntu-kpi.kiev.ua>
Date: Fri, 07 Jun 2002 11:19:50 +0300
Links: << >>  << T >>  << A >>
Look on Motorolla web site. They have own implementation of PowerPC cpu.

Best regards ,Vladislav

Laurent Gauch wrote:

> Hi all,
>
> Do you know a good book on the PowerPC architecture (with OPB LPB
> arbitrer description)!
>
> (for introducing my students)
>
> Laurent


Article: 43956
Subject: Help - Xilinx SRL16 primitive gives 'X's in simulation
From: Iain Waugh <iain@zip.com.au>
Date: Fri, 7 Jun 2002 18:45:27 +1000
Links: << >>  << T >>  << A >>
Hi,

I am simulating a design which uses an SRL16 primitive from the unisims
library.

Every 9th clock cycle or so, I get an 'X' on the Q output.

The design is fully synchronous.  There are no 'X's on the inputs and
the 'A0' - 'A3' inputs are tied to '1'.

Any ideas what's going on?

Does it have something to do with the way the shift register is defined
in the 'unisim_VITAL.vhd' library ('16 downto 0' is 17 bits!)?
 signal SHIFT_REG : std_logic_vector (16 downto 0) := ('X' &
To_StdLogicVector(INIT));

Cheers,
--
                 .    .                 Iain Waugh
 . o  ._o   .o    \#/.   o.   o_.  o .  iain@zip.com.au
  `)   /\   =)  .-kai-   )=   /\   )'   http://www.zip.com.au/~iain
  /<    <    <    /#\ .  >    >    >\   :.::.:TAG.:.::.
                .


Article: 43957
Subject: Re: FPGA destruction vs power management
From: Guido Pohl <pohl@fokus.fhg.de>
Date: Fri, 07 Jun 2002 09:07:58 GMT
Links: << >>  << T >>  << A >>
Mr. Lesea,

recently you wrote: (excerpt from your white paper pre-release)

> 
> In Virtex II and Virtex II Pro, low threshold (Vt) NMOS transistors are used to
> buffer the outputs of the pass gate multiplexers.  The low Vt NMOS transistors are
> leakier than the higher threshold PMOS transistors.  Choosing a logic high as the
> “normal” or “static” state (e.g. using inverted sense logic signal states) causes
> the NMOS to be ON, and the PMOS to be OFF, which exhibits less power than the other
> way around.


In one of your following answers you replied to a colleague of mine:


> If there are low Vt nmos transistors (in the interconnect), they have more leakage if the 
> outputs are '1' than  if they are at '0'.  Depending on where these are used, theystate of
> the logic will determine the output  condition.


I just want to ask if a figure will be included in the white paper describing the structure you are talking above?
(I recognise that drawing an ASCII figure here in the newsgroup is somewhat cumbersome ...)
I'd like to follow the train of thoughts - that' s the reason I encourage you to add some details. Where does the leakage current goes 
through? What is its path?

Thanks, Guido








Article: 43958
Subject: Re: Quick newbie question...
From: "Torbjörn Stabo" <torbjorndotstabo@etxdotericssondotse.invalid>
Date: Fri, 7 Jun 2002 15:32:49 +0200
Links: << >>  << T >>  << A >>
> Anyway, am using a Spartan II and will use an XC18V02 PROM. When I
power-up,
> does the PROM begin to program the FPGA immediately after the power levels
> are stable?
>
> adrian

Adrian, you might want to look up "mode pins" or something in Xilinx's
SpartanII
documentation. Whether or not the prom starts to load "immediately" depends
on
how you wire those pins.
/HTH, Torbjörn Stabo



Article: 43959
Subject: Re: IOSTANDARD
From: hamish@cloud.net.au
Date: 07 Jun 2002 13:50:46 GMT
Links: << >>  << T >>  << A >>
cfk <cfk_alter_ego@pacbell.net> wrote:
> I innocently added NET "PCICLK" IOSTANDARD="PCI33_3" to my UCF file. To my
> surprise, there was no difference in the ringing and overshoot. I tried
> making it a syntax error to convince myself that this file really was being
> read by the ISE software and yes it is. So, I guess one of two things is

The tools are notoriously bad for ignoring incorrect IOSTANDARDs.
Generally, these get changed back to LVTTL, and only MAP with the
detailed report enabled will even tell you that it occurred. The
IOSTANDARDs are case sensitive too! (from memory).

Check the pad report in the PAR log file (versions <= 4.1 only),
or the MRP map report, or perhaps the PAD report. One of them
has the IO standards actually used for each pin.


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

Article: 43960
Subject: Re: xc3042
From: hamish@cloud.net.au
Date: 07 Jun 2002 13:56:18 GMT
Links: << >>  << T >>  << A >>
F.M. Fontaine <fontain@nlr.nl> wrote:
> I think that XACTStep 6.0.1 (which actually is XACT 5.2.1) from november
> 1996 is the last version to support the original XC2000/XC3000/XC4000
> families.
> XACTStep 6.0.1. is a windows version (originally Win 3.11) which will run
> under Win95, I don't know if it will run under NT, 98, ME, 2000 or XP.
> XACT 5.2.1 is a DOS version of the same core-tools.

> Both version require a dongle ...

Most likely it will refuse to read the EDIF from modern synthesis tools
too. EDIF version too new, from memory. Maybe I'm mistaken.

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

Article: 43961
Subject: Re: Xilinx guided PAR problem
From: hamish@cloud.net.au
Date: 07 Jun 2002 13:57:24 GMT
Links: << >>  << T >>  << A >>
Rick <rickspxmgoaway@algor.co.uk> wrote:
> it seemed like a good candidate for ``exact'' mode. This worked fine in
> that it matched 100% of the components and 100% of the signals and PAR
> finished in next to no time .... Unfortunately it totally failed to
> routed any of the PWR/GND connections - even after a second attempt
> using the re-entrant routing -k flag!

> Anyone seen this problem ? it doesn't seem to be mentioned in the
> answers database.

> Trying again with ``leveraged'' mode lead to 370 comps that guided
> placement failed to put back,  ~5000 connections unrouted, an overall
> routing time much greater than the first one [which had hit the timing
> contraints in the first pass], and a small contsraint failure (32ps
> total).

Rick, are you using guided MAP as well as guided PAR?
Guided MAP helps PAR to match placements in my experience.


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

Article: 43962
Subject: Re: Xilinx guided PAR problem
From: Rick <rickspxmgoaway@algor.co.uk>
Date: Fri, 07 Jun 2002 15:16:04 +0100
Links: << >>  << T >>  << A >>


hamish@cloud.net.au wrote:

> Rick <rickspxmgoaway@algor.co.uk> wrote:
> > it seemed like a good candidate for ``exact'' mode. This worked fine in
> > that it matched 100% of the components and 100% of the signals and PAR
> > finished in next to no time .... Unfortunately it totally failed to
> > routed any of the PWR/GND connections - even after a second attempt
> > using the re-entrant routing -k flag!
>
> > Anyone seen this problem ? it doesn't seem to be mentioned in the
> > answers database.
>
> > Trying again with ``leveraged'' mode lead to 370 comps that guided
> > placement failed to put back,  ~5000 connections unrouted, an overall
> > routing time much greater than the first one [which had hit the timing
> > contraints in the first pass], and a small contsraint failure (32ps
> > total).
>
> Rick, are you using guided MAP as well as guided PAR?
> Guided MAP helps PAR to match placements in my experience.
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

O.k. I'll give that a try - both ``exact'' & ``leveraged''.



Article: 43963
Subject: Re: xc3042
From: Rick <rickspxmgoaway@algor.co.uk>
Date: Fri, 07 Jun 2002 15:28:57 +0100
Links: << >>  << T >>  << A >>


hamish@cloud.net.au wrote:

> F.M. Fontaine <fontain@nlr.nl> wrote:
> > I think that XACTStep 6.0.1 (which actually is XACT 5.2.1) from november
> > 1996 is the last version to support the original XC2000/XC3000/XC4000
> > families.
> > XACTStep 6.0.1. is a windows version (originally Win 3.11) which will run
> > under Win95, I don't know if it will run under NT, 98, ME, 2000 or XP.
> > XACT 5.2.1 is a DOS version of the same core-tools.
>
> > Both version require a dongle ...
>
> Most likely it will refuse to read the EDIF from modern synthesis tools
> too. EDIF version too new, from memory. Maybe I'm mistaken.
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

May even be worse than that since my memory says that the XACT tool's native
netlist format was XNF and EDIF didn't come in until the M1.X tools.

BTW Anyone know just who was responsible for the choice/design of EDIF? The
Lisp idiocy means it dismally and completely fails the most basic requirement
of any EDA language or format - "Can it be parsed/hacked with Perl ?".




Article: 43964
Subject: Re: Xilinx ise software?
From: "Mikhail Matusov" <misoma@ANNTI-rogers-SPPAMM.com>
Date: Fri, 07 Jun 2002 14:38:11 GMT
Links: << >>  << T >>  << A >>

> Xilinx publishes two different software products:
>
> 1. Alliance
>
> It only has P&R tools. You must have a synthesizer program to generate
> gate-level description out of a hardware programming language like VHDL,
> Verilog. An example of synthesizer program is Synplicity's Synplify
> (http://www.synplicity.com). Company name is Synplicity, product name is
> Synplify.
>
> 2. Foundation
>

This is how it used to be. I am not sure whether P&R only package is still
available, but the Foundation certainly is being phased out and replaced
with the Xilinx ISE, which is a full design environment including synthesis,
etc. Up to May 31st there was a choice of synthesis tool that one could use
with it, either FPGA Express or Xilinx XST. As far as I understand the
agreement between Xilinx and Synopsys is now over and new users can no
longer purchase FPGA Express through Xilinx.


--
============================
Mikhail Matusov
Hardware Design Engineer
Square Peg Communications
Tel.: 1 (613) 271-0044 ext.231
Fax: 1 (613) 271-3007
http://www.squarepeg.ca




Article: 43965
Subject: Thresholds
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 07 Jun 2002 07:39:03 -0700
Links: << >>  << T >>  << A >>
Guido,

I must refrain from getting into too many details, as the circuits vary from family to family, based on the available technolgies from our
foundry partners.  If you visit a foundry website (TSMC, UMC, IBM) you will see what the available process devices are for any given
technology node (eg .13u).

If you are interested in this topic, I sugggest you use the USPTO (US Patentent and Trade Mark Office) website, and search through the
patents on the subject.

As well, the Berkeley Wireless Center Research Group has a PhD Thesis posted on the subject.

The use of low Vt transistors is commonly referred to as the "high speed" transistors, and microprocessor designers use them almost
exclusively.  I am sure that there is a lot of literature on this subject as well out there.

To discuss the actual particulars of how the device is designed is something we consider proprietary and confidential.

The information that I posted on power management is also in a paper that was given at a recent conference, and hence is also public
knowledge.  It is sufficent to say that if you have a choice of the logic state of signals, choosing logic high = true, or logic low =
true may result in a small power savings at high temepratures due to the lowered leakage.  If the signals are transistioning ~50% of the
time, it makes no difference.

Even in 0.13u, the leakage current is not much of a factor (say the way it is in a microprocessor, where as much as 50% of the power is DC
leakage at hot).  I hardly expect anyone to save any power by this means until we get to even smaller gate lengths.

Austin


Guido Pohl wrote:

> Mr. Lesea,
>
> recently you wrote: (excerpt from your white paper pre-release)
>
> >
> > In Virtex II and Virtex II Pro, low threshold (Vt) NMOS transistors are used to
> > buffer the outputs of the pass gate multiplexers.  The low Vt NMOS transistors are
> > leakier than the higher threshold PMOS transistors.  Choosing a logic high as the
> > “normal” or “static” state (e.g. using inverted sense logic signal states) causes
> > the NMOS to be ON, and the PMOS to be OFF, which exhibits less power than the other
> > way around.
>
> In one of your following answers you replied to a colleague of mine:
>
> > If there are low Vt nmos transistors (in the interconnect), they have more leakage if the
> > outputs are '1' than  if they are at '0'.  Depending on where these are used, theystate of
> > the logic will determine the output  condition.
>
> I just want to ask if a figure will be included in the white paper describing the structure you are talking above?
> (I recognise that drawing an ASCII figure here in the newsgroup is somewhat cumbersome ...)
> I'd like to follow the train of thoughts - that' s the reason I encourage you to add some details. Where does the leakage current goes
> through? What is its path?
>
> Thanks, Guido


Article: 43966
Subject: VirtexE LVDS problem / question
From: "Dan Kuechle" <danielgk@voomtech.com>
Date: Fri, 7 Jun 2002 10:25:15 -0500
Links: << >>  << T >>  << A >>
I have an well established VirtexE design (schematic) that uses a couple of
LVDS inputs.  All other
I/O is 3.3v TTL.  All the I/O Vcc pins are connected to 3.3v.  No errors are
reported, and the design
has been in production and working for over a year.  I now get a request to
turn one of the LVDS
pairs into an I/O so a non-time-critical LVDS signal (reset) can be driven
by the fpga.  When I make
the changes, I get errors saying I have banking violations and that the bank
with the LVDS output
should be at 2.5v.  When I make all other TTL I/O's in the bank LVCMOS2
instead of the default
LVTTL my design compiles with out error, but it also assumes the bank will
be at 2.5v.

What will happen when this bank is connected to 3.3v?
As stated before, timing on the LVDS output is not an issue.


Thanks
   Dan



Article: 43967
Subject: Re: Help - Xilinx SRL16 primitive gives 'X's in simulation
From: John_H <johnhandwork@mail.com>
Date: Fri, 07 Jun 2002 15:28:43 GMT
Links: << >>  << T >>  << A >>
The simulation primitive might not be up to snuff.  In my post P&R Verilog
simulations I had to replace the instances of X_SRL16E.v with my own
version to get around a bogus timing problem.  Changing the file to add a
#2 (2 ps delay) in front of "{data[15:0} <= {data[14:0],d_in};" took care
of it for me.  The problem may be the same in the VDHL simprim.

If you look into the simprim with your simulator you may find just where
the simprim decides the "X" is declared.  The "notifier" in the Verilog was
the key element that gave me my X.

- John_H


Iain Waugh wrote:

> Hi,
>
> I am simulating a design which uses an SRL16 primitive from the unisims
> library.
>
> Every 9th clock cycle or so, I get an 'X' on the Q output.
>
> The design is fully synchronous.  There are no 'X's on the inputs and
> the 'A0' - 'A3' inputs are tied to '1'.
>
> Any ideas what's going on?
>
> Does it have something to do with the way the shift register is defined
> in the 'unisim_VITAL.vhd' library ('16 downto 0' is 17 bits!)?
>  signal SHIFT_REG : std_logic_vector (16 downto 0) := ('X' &
> To_StdLogicVector(INIT));
>
> Cheers,
> --
>                  .    .                 Iain Waugh
>  . o  ._o   .o    \#/.   o.   o_.  o .  iain@zip.com.au
>   `)   /\   =)  .-kai-   )=   /\   )'   http://www.zip.com.au/~iain
>   /<    <    <    /#\ .  >    >    >\   :.::.:TAG.:.::.
>                 .


Article: 43968
Subject: Re: Problem with spartan2 vhdl code
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Fri, 7 Jun 2002 18:32:31 +0200
Links: << >>  << T >>  << A >>
Hi Mr. Modderkolk,

try this, it detects rising and/or falling edges of your switch.
If you need more VHDL examples,  just download
the examples of our Spartan-2 development boards
from www.cesys.com (go to download-section)
Have a nice day
Manfred Kraus



library IEEE;
use IEEE.std_logic_1164.all;

entity EdgeDetect is
    port (
        SCLK: in STD_LOGIC;
        Reset: in STD_LOGIC;
        Input: in STD_LOGIC;
        O: out STD_LOGIC;
        Rise: in STD_LOGIC;
        Fall: in STD_LOGIC;
        Enable: in STD_LOGIC
    );
end EdgeDetect;

architecture EdgeDetect_arch of EdgeDetect is

signal OldValue: STD_LOGIC;
signal SyncIn: STD_LOGIC;

begin


SyncInput: process (SCLK, Input)
begin
  if (SCLK = '1' AND SCLK'EVENT) then
    SyncIn <= Input;
  end if;
end process;


EdgeDetect: process (SCLK, RESET, OldValue, SyncIn)
begin
  if (RESET = '1') then
    O <= '0';
  elsif (SCLK = '1' AND SCLK'EVENT) then
    if (ENABLE = '1' AND RISE = '1' AND OldValue = '0' AND SyncIn = '1') OR
       (ENABLE = '1' AND FALL = '1' AND OldValue = '1' AND SyncIn = '0')
then
      O <= '1';
    else
      O <= '0';
    end if;
  end if;
end process;


process (SCLK, RESET, SyncIn)
begin
  if (SCLK = '1' AND SCLK'EVENT) then
    OldValue <= SyncIn;
  end if;
end process;


end EdgeDetect_arch;




"F. Modderkolk" <frankmotje@hotmail.com> schrieb im Newsbeitrag
news:82eb64d2.0206032335.39c179aa@posting.google.com...
> If I test the vhdl code with modelsim, it works just fine, but when I
> implement it, it doesn't do anything. The function of the code is to
> create a puls with a lenght of one clockpuls when I push a button
>
> the code:
>
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
> entity startertwee is
>     Port ( puls : in std_logic;
>            pulsuit : out std_logic;
>            clk : in std_logic;
>            stopenreset : in std_logic);
> end startertwee;
>
> architecture Behavioral of startertwee is
> signal intern : std_logic;
> signal bpulsuit : std_logic;
>
> begin
> process (clk)
> begin
> if clk'event then
> if stopenreset = '1' then
>   pulsuit <= '0';
> intern <= '0';
> bpulsuit <= '0';
> else
> if clk  = '1' then
> if puls = '1' and intern = '0' then
> bpulsuit <= '1';
> intern <= '1';
> elsif puls = '0' and intern = '1' then
> intern <= '0';
> bpulsuit <= '0';
> else
> bpulsuit <= '0';
> intern <= intern;
> end if;
> end if;
>
> if clk = '0' then
> pulsuit <= bpulsuit;
> end if;
> end if;
> end if;
> end process;
> end Behavioral;
>
>
> Is there something I forget to program or something I do wrong?
> I hope you can help me
> thx



Article: 43969
(removed)


Article: 43970
Subject: Re: Help - Xilinx SRL16 primitive gives 'X's in simulation
From: Ray Andraka <ray@andraka.com>
Date: Fri, 07 Jun 2002 17:51:32 GMT
Links: << >>  << T >>  << A >>
The unisims SRL16 has a timingcheckson generic which you'll need to set to
false if you are simulating this with RTL level code, otherwise the delays will
cause it to clock data in wrong.  It is possible that unknown data is getting
clocked in.  The model has a 17 bit vector with the last one set to 'X' to
handle some of the special cases, don't worry about that.

If turning the timingchecks off doesn't fix you problem, it would be helpful if
you would post the snippet of code including the logic feeding the SRL16 so
that we could see what you are doing.  Could be an RTL flip-flop that is not
initialized feeding into it too.

John_H wrote:

> The simulation primitive might not be up to snuff.  In my post P&R Verilog
> simulations I had to replace the instances of X_SRL16E.v with my own
> version to get around a bogus timing problem.  Changing the file to add a
> #2 (2 ps delay) in front of "{data[15:0} <= {data[14:0],d_in};" took care
> of it for me.  The problem may be the same in the VDHL simprim.
>
> If you look into the simprim with your simulator you may find just where
> the simprim decides the "X" is declared.  The "notifier" in the Verilog was
> the key element that gave me my X.
>
> - John_H
>
> Iain Waugh wrote:
>
> > Hi,
> >
> > I am simulating a design which uses an SRL16 primitive from the unisims
> > library.
> >
> > Every 9th clock cycle or so, I get an 'X' on the Q output.
> >
> > The design is fully synchronous.  There are no 'X's on the inputs and
> > the 'A0' - 'A3' inputs are tied to '1'.
> >
> > Any ideas what's going on?
> >
> > Does it have something to do with the way the shift register is defined
> > in the 'unisim_VITAL.vhd' library ('16 downto 0' is 17 bits!)?
> >  signal SHIFT_REG : std_logic_vector (16 downto 0) := ('X' &
> > To_StdLogicVector(INIT));
> >
> > Cheers,
> > --
> >                  .    .                 Iain Waugh
> >  . o  ._o   .o    \#/.   o.   o_.  o .  iain@zip.com.au
> >   `)   /\   =)  .-kai-   )=   /\   )'   http://www.zip.com.au/~iain
> >   /<    <    <    /#\ .  >    >    >\   :.::.:TAG.:.::.
> >                 .

--
--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: 43971
Subject: Re: IOSTANDARD
From: "cfk" <cfk_alter_ego@pacbell.net>
Date: Fri, 07 Jun 2002 18:37:00 GMT
Links: << >>  << T >>  << A >>
I have to say that I looked with my scope and did not see any significant
changes day before yesterday. Yesterday, I stored the clock waveform (I am
trying to emit a PCICLK) with both LVTTL and PCI33_33 and compared the
waveforms. It turns out that the IOSTANDARD was changing in a more subtle
fashion then I was looking for. The gist of it is that the rise and fall
times were changing with IOSTANDARD, but not the over/undershoot. So, I can
say that IOSTANDARD was being set from the UCF file in ISE. It just turned
out that I needed a 56ohm series resistor on my clock line to bring the
over/undershoot back to reasonable.

Thank you for your comment hamish, and I will study the PAR report.

Charles

<hamish@cloud.net.au> wrote in message
news:3d00ba36$0$31828$afc38c87@news.optusnet.com.au...
> cfk <cfk_alter_ego@pacbell.net> wrote:
> > I innocently added NET "PCICLK" IOSTANDARD="PCI33_3" to my UCF file. To
my
> > surprise, there was no difference in the ringing and overshoot. I tried
> > making it a syntax error to convince myself that this file really was
being
> > read by the ISE software and yes it is. So, I guess one of two things is
>
> The tools are notoriously bad for ignoring incorrect IOSTANDARDs.
> Generally, these get changed back to LVTTL, and only MAP with the
> detailed report enabled will even tell you that it occurred. The
> IOSTANDARDs are case sensitive too! (from memory).
>
> Check the pad report in the PAR log file (versions <= 4.1 only),
> or the MRP map report, or perhaps the PAD report. One of them
> has the IO standards actually used for each pin.
>
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>



Article: 43972
Subject: Doing Trig Functions in FPGA, EPLD
From: junk@junk.net (Anton Erasmus)
Date: Fri, 07 Jun 2002 18:39:37 GMT
Links: << >>  << T >>  << A >>
Hi,

I have done simple EPLDs with device like Altera EPM7064 and 10K Flex
series. So far I have used AHDL.
How difficult is it to do math functions such as axis transformations
in an EPLD ? I am trying to find out whether it would be possible to
use a smallish EPLD / FPGA such as a FLEX 10K10 or 10K20 to
provide meaningfull acceleration of axis transformation done with
an 8 bit processor. The calculations are done in floating point, and
the slowest functions are the sin, cos functions. 
I would be greatfull for any input regarding this.

Regards
   Anton Erasmus


Article: 43973
Subject: opencore PCI bridge versus LogiCORE
From: "cfk" <cfk_alter_ego@pacbell.net>
Date: Fri, 07 Jun 2002 18:45:39 GMT
Links: << >>  << T >>  << A >>
I need to implement a PCI interface in a VirtexE 2000 device. I have been
studying the opencore PCI-Wishbone bridge and I can synthesize it in ISE and
load the bitstream into my VirtexE. It turns out also in this project, that
there is no motherboard with a PCI system controller, so I have implemented
control of RST, a PCICLK generator (which now works after I fixed the
rise/fall times and under/overshoot). I also have an arbiter module, so I am
creating the system controller in the same Virtex.

I have to say that I have seen mixed comments on the opencore PCI-Wishbone
bridge, and yesterday, I attended a meeting where the subject of changing
the PCI interface from PCI32/33 to PCI64/33 was discussed. That very well
will send me towards LogiCORE as the PCI-Wishbone bridge is PCI32/33 only.

I would appreciate a discussion of success or failure from others that have
used the PCI-Wishbone bridge and also a discussion of the relative merits of
the various Xilinx LogiCORE offerings. I see three varying in cost from $10K
to $20K and quite frankly I cant see which should be picked. I also see
mention of the fact that the IP seems to have significant strings attached
to it, in that the bitstream needs to be downloaded from the so-called
"Xpresso" cafe, and it doesnt appear that I may get to change the code for
my custom, non-motherboard implementation.

I thank you all in advance, Charles



Article: 43974
Subject: Re: Doing Trig Functions in FPGA, EPLD
From: Ray Andraka <ray@andraka.com>
Date: Fri, 07 Jun 2002 19:04:46 GMT
Links: << >>  << T >>  << A >>
Download a copy of my paper "A Survey of CORDIC algorithms for FPGA based
computers" from the publications page on my website.  CORDIC is a
shift-add algorithm for rotating vectors in the X-Y plane, and can be
used for both R->P and P->R conversions, magnitude, simultaneous sine and
cosine and other functions.  To handle floating point, you'll need a
complex normalize in front of it to weight both the I and Q the same and
some rescaling possibly at the output.  A bit serial sequential machine
can be made pretty small, or you can go to a fully parallel architecture
if performance is your goal.  I've done CORDIC rotators in Flex10K and
20K in the past.

Anton Erasmus wrote:

> Hi,
>
> I have done simple EPLDs with device like Altera EPM7064 and 10K Flex
> series. So far I have used AHDL.
> How difficult is it to do math functions such as axis transformations
> in an EPLD ? I am trying to find out whether it would be possible to
> use a smallish EPLD / FPGA such as a FLEX 10K10 or 10K20 to
> provide meaningfull acceleration of axis transformation done with
> an 8 bit processor. The calculations are done in floating point, and
> the slowest functions are the sin, cos functions.
> I would be greatfull for any input regarding this.
>
> Regards
>    Anton Erasmus

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





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