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 37200

Article: 37200
Subject: Announce: TimingAnalyzer Program Update
From: d2fabrizio@aol.com (D2fabrizio)
Date: 03 Dec 2001 21:00:48 GMT
Links: << >>  << T >>  << A >>
Hello All,

The TimingAnalyzer can be used to draw and document 
timing diagrams of digital systems.

A new version beta0.60 is now available. Registration is
no longer needed so a password is included.

This version includes a significant change in the GUI.
You can edit mulitple timing diagrams displayed in 
tab panes or views. You can see this at:

http://members.aol.com/d2fabrizio/main_pic.html

Below is a complete list of all the changes.

Regards,
Dan Fabrizio
d2fabrizio@aol.com
http://members.aol.com/d2fabrizio

--------------------------------------------------------------------------
-------------------------------------   

Version 0.60

  New Features

    1  A major change in the GUI.
       Multiple diagrams can be displayed in tabbed panes.
       Any tab pane can show the timing diagram or image diagram.

    2  Multiple views, top and bottom, can display multiple timing diagrams.
       Cut, copy, paste objects between visible diagrams in the top and
       bottom views. In future, drag and drop will be added.

    3  Diagrams left open when quitting are automatically loaded 
       when started again. A file called .taOpenFileList in the 
       user home dir keeps a list of files being edited between sessions.

    4  Double click on any edge to change the edge time or next state.

    5  Mouse drags all edges selected. 
       Left and right arrow keys also move edges as before.

    6  Mouse drags all text objects selected. 
       Left and right arrow keys also move text objects as before.

    7  Clock Divide by N function.

    8  Edge Detector function.
  
  Improvements

    1  Digital Bus state format ( Hex, Bin, Dec, or Text ) can be
       changed at anytime. Conversion from and to Text has been added.

    2  More consistent dialog operation when updating or adding Objects.

    3  Improved file I/O performance.  ( file format change )

    4  DigitalBus now displays "0" and "1" correctly.



Article: 37201
Subject: Re: Phase noise (jitter) of XILINX logic elements - ?
From: "Alex Sherstuk" <sherstuk@iname.com>
Date: Mon, 03 Dec 2001 21:52:59 GMT
Links: << >>  << T >>  << A >>
Austin,

  Thank you for valuable information.

So, if I want to reduce the jitter on XILINX output to something like 10
ps - I have to use some external triggers, clocked by extremely pure
frequency.

And here the next question appears:
    who manufactures low noise triggers?

Is that true, that regular ALS logic flip-flops are introducing 15 - 20 ps
jitter?

I guess, of course, there are some better triggers, - at least for expensive
jitter-measurement systems.
What kind of triggers?

Thanks,
  Alex


"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3C0B9EB9.AAFCC010@xilinx.com...
> Alex,
>
> I prefer to look at this as "what is the jitter noise floor" in a CMOS
FPGA?
>
> Getting in, and getting out of the FPGA is the biggest problem, followed
by the
> internal distribution of the clock signals.
>
> This is something we have carefully characterized, as we are the 'FPGA
Lab'
> responsible for the verification of the design.
>
> To get in, get onto a BUFG (global clock resource) and then get out (by
using
> the DDR clock forwarding FF's) is about 35 to 55 ps P-P (nothing else
> happening).
>
> If you have an another BUFG operating, the jitter goes up to 55 ps to 65
ps P-P.
>
> If you then have 10% of all nodes in a 2V3000 all toggle at the same time
on the
> same clock domain (BUFG), the jitter measured is ~ 150 ps P-P on an
> ansynchronous clock domain.
>
> The primary means of jitter is the coupling through the ground, which
affects
> the slicing level of all of the logic.
>
> Use of LVDS input buffers, and output buffers helps for the external
jitter
> contributors, but does nothing for the internal contributors.
>
> 150 ps P-P of jitter in a design was ignored up until recently.  With DDR
> (double data rate) logic designs, and clock periods of 4 ns in some
designs, the
> half clock period is 2 ns, and 150 ps becomes a significant part of the
timing
> budget.
>
> See:
>
>  http://www.xilinx.com/support/techxclusives/slack-techX21.htm
>
> Austin
>
> Alex Sherstuk wrote:
>
> > Dear colleagues,
> >
> > Some time ago there was discussion about phase noise (jitter) introduced
by
> > XILINX FPGA DLL's
> >
> > Here is an other question:
> >
> > What phase noise (jitter) is introduced by a regular logic element of
XILINX
> > FPGA (e.g. SPARTAN2)?
> > What is the timing uncertainty introduced by XILINX CLB trigger?
> >
> > Thanks,
> >    Alex
>



Article: 37202
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Neil Franklin <neil@franklin.ch.remove>
Date: 03 Dec 2001 23:00:55 +0100
Links: << >>  << T >>  << A >>
Simon Gornall <simon@gornall.net> writes:

> FPGA's are the new 80's PC's

> I do feel there is some merit in the statement that FPGA's are now at
> the point where PC's were at 15 years ago.

Ah, someone to my liking :-).


> I would *really* like
> to not have to reboot into Win2k to run the tools though - in fact the
> main obstacle to the development of my "project" is that my Linux box
> is usually busy doing things, and I don't want to interrupt it to play
> on the FPGA stuff. Guess I should buy another computer ...

You seem to not know that you can develop for Virtex (without -E) and
those Spartan-II models that have equivalent Virtex sizes under Linux.

I am initially targetting the same BurchED board, and I have been 100%
Microsoft-free for 5 years now. And I do not have a Solaris box either.

The trick is to use Xilixes JBits toolsset. It is also a free (as in
beer) download from Xilinx. Only problem is that since 2.6 the
installer craps out under some Linux distributions (Debian and
Slackware for sure), so one needs to borrow time on an Solaris box to
do the install there, then .tar.gz it and unpack on Linux.

JBits is a bit unusual in that is is totally low-level (you trigger
individual chip features). For a look at how using it is like, try my
project source at:

http://neil.franklin.ch/Projects/PDP-10/pdp10.java


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery

Article: 37203
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Neil Franklin <neil@franklin.ch.remove>
Date: 03 Dec 2001 23:04:30 +0100
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:

> Neil Franklin wrote:
> >
> > My method to save time is to actually have no bus at all. Rather
> > SDRAM sockets and set of standard IO connectors driven directly
> > (or with only a bit of analog stuff between) from the FPGA. "Bus"
> > is only internal, longlines or even user multiplexers. Also gives
> > maximal flexibility to different architectures.
>
> Exactly what do you consider to be a "standard" IO connector?

Oops. That term can be misunderstood. :-)


> I assumed
> that you meant PCI, ISA, IDE ect.

I was thinking of VGA, PS/2, LPT, RS232, FDD, IDE, Ethernet and so on.


> If you want to put all that interface
> inside of the FPGA that will require more work on your part to design
> the interfaces.

As I have got to clone the register sets of the historic IO devices,
actually implementing the functionality should follow.


> If you use an existing MB, you only have to design your
> CPU with a single bus interface.

And then port the old systems OS to an totally new memory map and IO
devices.

I know from the original historic systems developers who are following
my project, that such an port was for them a multi-year job.


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery

Article: 37204
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Neil Franklin <neil@franklin.ch.remove>
Date: 03 Dec 2001 23:08:07 +0100
Links: << >>  << T >>  << A >>
Andy Peters <andy@exponentmedia.deletethis.com> writes:

> Neil Franklin wrote:
>
> > Presently my real application is my design for running on such an
> > board (and being developed on an normal prototype board). Custom board
> > will follow after, to let more users use the design with less hassle.
>
> What's a "normal prototype board"?  Don't tell me you're gonna wire-wrap
> this thing.

Present intended board is the BurchED XC2S200 prototype board. For the
newest revicion (B5) that gives 8 20pin connectors. What I will be
putting on them I will decide when I am so far.


> Question: which open-source PCB layout tool will you be using for your
> custom circuit-board layout?

Not decided. Not even investigated the issue yet.

As said: first coding for the BurchED, parallel developing some
tools. Then when users want to use the design (in perhaps 2 years) a
board will be needed.


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery

Article: 37205
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Simon Gornall <simon@gornall.net>
Date: Mon, 03 Dec 2001 22:28:11 +0000
Links: << >>  << T >>  << A >>
Neil Franklin wrote:
> 
> Simon Gornall <simon@gornall.net> writes:
> 
> > FPGA's are the new 80's PC's
> 
> > I do feel there is some merit in the statement that FPGA's are now at
> > the point where PC's were at 15 years ago.
> 
> Ah, someone to my liking :-).
> 
> > I would *really* like
> > to not have to reboot into Win2k to run the tools though - in fact the
> > main obstacle to the development of my "project" is that my Linux box
> > is usually busy doing things, and I don't want to interrupt it to play
> > on the FPGA stuff. Guess I should buy another computer ...
> 
> You seem to not know that you can develop for Virtex (without -E) and
> those Spartan-II models that have equivalent Virtex sizes under Linux.

Thanks for the info, Neil, I'll look into it :-)

ATB,
	Simon.

Article: 37206
Subject: Re: What do you like/dislike about place and route tools?
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 03 Dec 2001 23:32:02 +0100
Links: << >>  << T >>  << A >>
mrgs1000@yahoo.com (Mark) writes:

> I am doing some research on place and route tools. I would like to
> collect as much information as possible about them. My primary focus
> is on Xilinx, but I would like to know if there are particular
> features on other vendors tools that you like or dislike.


I like performance. 

Most place and route algorithms are building some kind of search tree
with an estimate of timing, congestion, etc. I think these
applications would run quite effectively on clusters of workstations
(or PC's).

I would like to see place and route tools implementing distributed
algorithms so I could increase the throughput (not necessarily
linearly) by throwing cheap $2000 PC's at the problem...

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 37207
Subject: Re: Phase noise (jitter) of XILINX logic elements - ?
From: John_H <johnhandwork@mail.com>
Date: Tue, 04 Dec 2001 00:30:05 GMT
Links: << >>  << T >>  << A >>
I don't know for sure if the results are spectacular but when I was designing
jitter test equipment for telecom, the approach I wanted to persue was to use
single-gate registers.  At the time the pico-gate devices (someone's trademark,
I'm sure) or other associated small logic families didn't have registers
shipping, only planned.  The biggest reason jitter is introduced is crosstalk
between elements within the same package.  If there's only one element, how can
you have crosstalk?  The jitter steps down to even smaller effects.

If you treat the registers as analog elements - clean planes, nice clearance on
the traces to reduce crosstalk - you should get the clean edges you desire.  But
they'll never be more clean than the clock source that drives the registers -
that *must* be clean.



Alex Sherstuk wrote:

> Austin,
>
>   Thank you for valuable information.
>
> So, if I want to reduce the jitter on XILINX output to something like 10
> ps - I have to use some external triggers, clocked by extremely pure
> frequency.
>
> And here the next question appears:
>     who manufactures low noise triggers?
>
> Is that true, that regular ALS logic flip-flops are introducing 15 - 20 ps
> jitter?
>
> I guess, of course, there are some better triggers, - at least for expensive
> jitter-measurement systems.
> What kind of triggers?
>
> Thanks,
>   Alex


Article: 37208
Subject: Re: What do you like/dislike about place and route tools?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 04 Dec 2001 01:35:57 GMT
Links: << >>  << T >>  << A >>
Wow,  This sounds exactly like my complaints about Lattice 5 years ago (I
haven't used Lattice in a while).  So sad to hear that nothing has changed.

Andy Peters wrote:

> Well, here's a complaint about Lattice's tools.
>
> For some reason, Lattice thinks that designers care about how many logic
> levels it takes to implement a function.  See, I don't care.  All I care
> is that the finished design meets my timing constraints (and fits).
> Problem is, Lattice's tools don't know a timing constraint from a hole
> in the wall.  What their tools expect you to do is to pick a combination
> of fitter options, press "go" and after the place and route completes
> (if, in fact, it does), you have to manually go through the timing
> reports to see if you win or lose.  And when you lose, you have to go
> back in and pick a different bunch of options.  The fitter "effort"
> switch doesn't do what you think it does, it just picks a different
> algorithm.  The "Explore" feature is broken.
>
> If you want to take advantage of the fast I/O output enables, you have
> to set a constraint in a constraint file that's call "end critical
> path."  And the fitter will then warn you that there's "no combinational
> logic..." to minimize if you drive your output enable from a flop.  (It
> still "does the right thing," but the warning is stupid.)
>
> I've told the Lattice rep more than once: I want to be able to set a
> period constraint and I/O timing constraints, push the "start" button,
> and go get a cup of coffee or get some lunch, and come back and find my
> chip either routed or failed to meet timing (or it wouldn't fit).
>
> I haven't even mentioned how unroutable their chips are.
>
> ---a

--
--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: 37209
Subject: Re: What do you like/dislike about place and route tools?
From: Ken McElvain <ken@synplicity.com>
Date: Mon, 03 Dec 2001 17:47:49 -0800
Links: << >>  << T >>  << A >>


John_H wrote:

> I love seeing comments form others that reinforce the gripes I've had over
> time.
> 
> My experience with the Altera MaxPlus-II tools is dated with no Quartus to
> back mu up but what I saw then is consistent with what I continue to see
> in Xilinx:
> 
>    Nobody is doing "critical route" placement.


Take a look at the TOPS technology in Amplify.  It does it's own
complete placement of a region while doing timing optimization on
the logic.  It doesn't do the whole chip but regions can be pretty
large.  Virtex and Virtex-E only.

	http://www.synplicity.com/about/pressreleases/SYB-101final.html


> 
> In my opinion, the best way to place and route a design is to figure out
> what paths will be the most difficult to route.  When the delay paths with
> two carry chains and four levels of logic are routed first, the paths with
> two levels of logic should be cake to P&R with fewer resources available.
> I don't care if my logic goes from one corner to another if it doesn't
> impact the timing for that path and the critical routing resources have
> already been used.  What does irk me is finding part of my few tight paths
> getting placed inefficiently.  To have these critical paths in different
> rows in my Altera design or in different, non-adjacent CLBs in my Xilinx
> designs is irresponsible.
> 
> The Xilinx mapper in particular works against the concept of a critical
> route based place and route.  The idea that the design should 1) be placed
> then 2) be routed doesn't work (to any level of efficiency).  The P&R tool
> should be 1) place, 2) route, 3) place, 4) route, 5) place, etc....  At
> least in (an upcoming servicepack of) the version 4.1i tools there's some
> attention given to critical routes, though more of a ripup and retry
> approach.  Strike that, I think they refer to it as a retry:  no ripup of
> any paths that meet timing.  This is a big step in the right direction but
> still may be too little, too late in the P&R process to give the leaps in
> performance.
> 
> With the proper P&R strategies, the silicon that's been designed to kick
> some serious butt will finally be able to do just that.  Having the P&R
> kick the engineer in the butt really needs to stop.
> 
> I hope the research you're doing is toward a very good end!
> 
> 


Article: 37210
Subject: Re: Phase noise (jitter) of XILINX logic elements - ?
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 4 Dec 2001 02:01:28 GMT
Links: << >>  << T >>  << A >>
Austin Lesea <austin.lesea@xilinx.com> writes:

>I prefer to look at this as "what is the jitter noise floor" in a CMOS FPGA?

>Getting in, and getting out of the FPGA is the biggest problem, 
> followed by the internal distribution of the clock signals.

>This is something we have carefully characterized, as we are the 
>'FPGA Lab' responsible for the verification of the design.

>To get in, get onto a BUFG (global clock resource) and then get 
>out (by using the DDR clock forwarding FF's) is about 35 to 55 ps 
>P-P (nothing else happening).

>If you have an another BUFG operating, the jitter goes up to 55 ps 
>to 65 ps P-P.

This reminds me of a story about the TTL 74S124 (I think that is the
number) dual oscillator.  I was told that it was almost impossible
to use both, as they will phase lock if at all possible.

As I remember, phase locked oscillations were first discovered
by Huygens putting multiple pendulum clocks on the same wall.
You wouldn't expect the coupling to be large, but apparently enough.

OK, web search and I find:  

http://www.soundfeelings.com/products/alternative_medicine/music_therapy/entrainment.htm

So, might one expect problems with multiple, non-synchronous oscillator
inputs to the same FPGA?

-- glen

Article: 37211
Subject: Re: Synplify 7 and Xilinx 4.1 Pair
From: "Modelsim/Synplify/VCS/LDV/FPGA Express/Xilinx/Quar" <chens_w@yahoo.com.cn>
Date: Mon, 3 Dec 2001 18:18:39 -0800
Links: << >>  << T >>  << A >>
when i do a project,i need use many the thirdy EDA tool.They offen need various environment variable.Now i need a shell or script that can run the all tools i refer  from begin to end ,but i don't need to switch.
Have anyone done ?

Article: 37212
(removed)


Article: 37213
Subject: Re: 128-bit scrambling and CRC computations
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Tue, 04 Dec 2001 03:55:43 GMT
Links: << >>  << T >>  << A >>
On Mon, 03 Dec 2001 11:12:41 -0500, rickman <spamgoeshere4@yahoo.com>
wrote:

>Allan Herriman wrote:
>> Here's the logic generated by crctool for one bit of a 16 bit CRC with
>> 128 bit input word:
>> 
>> D := Data;      -- the input word
>> C := CRC;       -- the feedback word
>> 
>> NewCRC(0) := D(127) xor D(125) xor D(124) xor D(123) xor D(122) xor
>> D(121) xor D(120) xor D(111) xor D(110) xor D(109) xor
>> D(108) xor D(107) xor D(106) xor D(105) xor D(103) xor
>> D(101) xor D(99) xor D(97) xor D(96) xor D(95) xor
>> D(94) xor D(93) xor D(92) xor D(91) xor D(90) xor D(87) xor
>> D(86) xor D(83) xor D(82) xor D(81) xor D(80) xor D(79) xor
>> D(78) xor D(77) xor D(76) xor D(75) xor D(73) xor D(72) xor
>> D(71) xor D(69) xor D(68) xor D(67) xor D(66) xor D(65) xor
>> D(64) xor D(63) xor D(62) xor D(61) xor D(60) xor D(55) xor
>> D(54) xor D(53) xor D(52) xor D(51) xor D(50) xor D(49) xor
>> D(48) xor D(47) xor D(46) xor D(45) xor D(43) xor D(41) xor
>> D(40) xor D(39) xor D(38) xor D(37) xor D(36) xor D(35) xor
>> D(34) xor D(33) xor D(32) xor D(31) xor D(30) xor D(27) xor
>> D(26) xor D(25) xor D(24) xor D(23) xor D(22) xor D(21) xor
>> D(20) xor D(19) xor D(18) xor D(17) xor D(16) xor D(15) xor
>> D(13) xor D(12) xor D(11) xor D(10) xor D(9) xor D(8) xor
>> D(7) xor D(6) xor D(5) xor D(4) xor D(3) xor D(2) xor
>> D(1) xor D(0) xor C(8) xor C(9) xor C(10) xor C(11) xor
>> C(12) xor C(13) xor C(15);
>> 
>> (Switch to fixed point font.)
>> 
>> Here's the logic you'll end up with:
>> 
>> clock-----------------------+
>>                             |
>>         +-------+      +----------+
>>         | huge  |      | register |
>> input-->| xor   |----->|d        q|--+-> CRC out
>> (128)   | tree  | (16) |          |  |    (16)
>>         +-------+      +----------+  |
>>             ^                        |
>>             |                        |
>>             +------------------------+
>>                   feedback (16)
>> 
>> The "speed" is determined by the minimum clock period, which in this
>> case is limited by the number of logic levels in the xor tree - i.e.
>> the maximum delay between any flip flop output and any flip flop
>> input.
>> You can't do anything with this directly, as the feedback must happen
>> in a single clock cycle.
>> 
>> If you look more closely at the logic expression, you'll see that it
>> can be decomposed into the form (input xor feedback) where input is
>> the xor of a bunch of input bits, and feedback is the xor of a bunch
>> of feedback bits.
>> 
>> This leads to the following design:
>> 
>> clock--------------------------------------+
>>                                            |
>>         +-------+      +-------+      +----------+
>>         | medium|      | small |      | register |
>> input-->| xor   |----->| xor   |----->|d        q|--+-> CRC
>> (128)   | tree  | (16) | tree  | (16) |          |  |   out
>>         +-------+      +-------+      +----------+  |   (16)
>>                            ^                        |
>>                            |                        |
>>                            +------------------------+
>>                                feedback (16)
>> 
>> This isn't any faster than the first attempt, but notice that the
>> "medium xor tree" is not in the feedback path.  This means it can be
>> pipelined - we can put flip flops in the logic so that the calculation
>> is performed over several clock cycles.  The logic depth between any
>> flip flop output and any flip flop input is reduced - we can have a
>> faster clock.
>> 
>> This is shown here:
>> 
>> clock-----------------------+-----------------------------
>>                             |
>>         +-------+      +----------+      +-------+      +-
>>         | medium|      | register |      | small |      |
>> input-->| xor   |----->|d        q|----->| xor   |----->|d
>> (128)   | tree  | (16) |          | (16) | tree  | (16) |
>>         +-------+      +----------+      +-------+      +-
>>                                              ^
>>                                              |
>>                                              +------------
>>                                                    feedbac
>> 
>> (I pruned the right side to avoid line wrap, but you should get the
>> idea.)
>> 
>> In theory the synthesis tools can do all this for you.  E.g. you can
>> describe a serial CRC calculation, put it in a for loop to iterate
>> over the input word, tell it how many clock cycles to take, and the
>> synthesiser should spit out something equivalent to the above.
>> (I have used this approach with LFSRs with some success at these bit
>> rates.)
>> 
>> I could make a comment about the relative benefits of HDLs and
>> schematics for high speed design, but I don't want to ignite yet
>> another religious war.
>> 
>> Regards,
>> Allan.
>
>I am not clear about how you generated this logic, but it does not match
>the general problem. Even though there are only 16 bits in the CRC,
>there should be 128 bits in the "feedback" register as well as in the
>input.

Are you sure about this, Rick?

I checked with other engineers here, and I checked a design that's
happily generating CRCs in the field, and it all points to a CRC-n
needing exactly 'n' bits of feedback regardless of the input word
width.

Perhaps you are trying to solve a different problem?

Regards,
Allan.

Article: 37214
Subject: Webpack Version 3: Exit with error code 0002
From: Brinda <brinda@glue.umd.edu>
Date: Mon, 3 Dec 2001 20:57:48 -0800
Links: << >>  << T >>  << A >>
Hi

I am trying to synthesise a simple receiver module. But I always get the error as above done: failed with exit code 0002.
It says that the module is correct for synthesis - extracts several signals before failing.
Can someone tell me what this means
please
Brinda

Article: 37215
Subject: Re: 128-bit scrambling and CRC computations
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 04 Dec 2001 00:06:55 -0500
Links: << >>  << T >>  << A >>
Allan Herriman wrote:
> >I am not clear about how you generated this logic, but it does not match
> >the general problem. Even though there are only 16 bits in the CRC,
> >there should be 128 bits in the "feedback" register as well as in the
> >input.
> 
> Are you sure about this, Rick?
> 
> I checked with other engineers here, and I checked a design that's
> happily generating CRCs in the field, and it all points to a CRC-n
> needing exactly 'n' bits of feedback regardless of the input word
> width.
> 
> Perhaps you are trying to solve a different problem?
> 
> Regards,
> Allan.

Or perhaps I am not remembering it correctly. I worked on this a year
ago and helped another engineer with a 128 bit version while I worked on
an 32 bit version. I may remember the details wrong. If the feedback is
only n bits, then getting the speed should be a slam dunk as long as you
can use pipelining for the inputs. 

-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 37216
Subject: Re: 128-bit scrambling and CRC computations
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Tue, 04 Dec 2001 05:38:42 GMT
Links: << >>  << T >>  << A >>
On Tue, 04 Dec 2001 00:06:55 -0500, rickman <spamgoeshere4@yahoo.com>
wrote:

>Allan Herriman wrote:
>> >I am not clear about how you generated this logic, but it does not match
>> >the general problem. Even though there are only 16 bits in the CRC,
>> >there should be 128 bits in the "feedback" register as well as in the
>> >input.
>> 
>> Are you sure about this, Rick?
>> 
>> I checked with other engineers here, and I checked a design that's
>> happily generating CRCs in the field, and it all points to a CRC-n
>> needing exactly 'n' bits of feedback regardless of the input word
>> width.
>> 
>> Perhaps you are trying to solve a different problem?
>> 
>> Regards,
>> Allan.
>
>Or perhaps I am not remembering it correctly. I worked on this a year
>ago and helped another engineer with a 128 bit version while I worked on
>an 32 bit version. I may remember the details wrong. If the feedback is
>only n bits, then getting the speed should be a slam dunk as long as you
>can use pipelining for the inputs. 

I make it that the clock rate is more-or-less determined solely by the
feedback, i.e. by the CRC order ('n').  For an 'm' bit input word, the
throughput is proportional to 'm'.  Just make the input bus wider, and
you get more bits per second, without limit!

You don't get something for nothing, though, as the number of 
pipeline stages on the input bus is something like O(log m), and the
number of flip flops is something like O(m log m).

Bye,
Allan.

Article: 37217
Subject: Re: I need a Xilinx Spartan PCI Development Board
From: sdfjsd <kljfsdlkfskljfds@kjflsdkjlfsdklfdslfsdklsdf.com>
Date: Tue, 04 Dec 2001 06:25:10 GMT
Links: << >>  << T >>  << A >>
> http://208.129.228.206/solutions/kits/xilinx/spartan-iipci.html
> 
> I used this kit to develop my own PCI IP core, and although the PCI IP
> core doesn't meet 33MHz PCI's timings (Tsu < 7ns and Tval < 11ns), the
> card somehow (barely) worked in two computers I tested it.
> It would have been nice if the Insight Electronics Spartan-II
> Development Kit used a 200K system gate part (XC2S200) instead of a
> 150K system gate part (XC2S150) even if the kit cost another $50 more,
> but overall I am very happy with the Insight Electronics Spartan-II
> Development Kit.

What does "barely" worked really mean?  I'm not intimately familiar
with PCI-protcol...I know that the PCI bus outputs (on a device)
are unregistered, to respond to the bus-protocol.  Are you saying that
the XCS2-150-5 device was barely fast enough to meet 33MHz timing?

Xilinx brazenly boasts that their Virtex family (the old 0.25micron
family) supports PCI66MHz/64-bit.  Your experience suggests that
while this can certainly be true, it's not an easily achievable
target for someone not designing specifically for FPGA.

Someone I know wants to develop a PCI-core for an in-house project.
He threw around the idea of prototyping it on an FPGA-board.
I advised him against it, simply because a lot of his design
implementation would be governed by the FPGA's architectire
(vs the actual production goal of a standard cell ASIC process.)

I reasoned he'd be wasting a lot of dev time making the core
work on an FPGA-device, i.e. wasting dev-time "designing for
FPGA", instead of just designing for the final project goal.

sorry if this is a redundant question...

Article: 37218
Subject: Re: I need a Xilinx Spartan PCI Development Board
From: Ray Andraka <ray@andraka.com>
Date: Tue, 04 Dec 2001 06:38:38 GMT
Links: << >>  << T >>  << A >>
IIRC, the VirtexE was the first family they claimed for 66MHz 64 bit.  To
get there, you need to use the TRDY logic that is embedded along the sides
of the array.  The synthesis tools and even the mapper and pAR don't know
about this little added logic, so if you need to use it, you have to go into
the FPGA editor and add it to the design.  Without it, I think you'll find
that you won't hit the 66 MHz 64 bit PCI spec, certainly not for the
original 2.5v Virtex, and I'm pretty sure not for the Virtex E either.

sdfjsd wrote:

> > http://208.129.228.206/solutions/kits/xilinx/spartan-iipci.html
> >
> > I used this kit to develop my own PCI IP core, and although the PCI IP
> > core doesn't meet 33MHz PCI's timings (Tsu < 7ns and Tval < 11ns), the
> > card somehow (barely) worked in two computers I tested it.
> > It would have been nice if the Insight Electronics Spartan-II
> > Development Kit used a 200K system gate part (XC2S200) instead of a
> > 150K system gate part (XC2S150) even if the kit cost another $50 more,
> > but overall I am very happy with the Insight Electronics Spartan-II
> > Development Kit.
>
> What does "barely" worked really mean?  I'm not intimately familiar
> with PCI-protcol...I know that the PCI bus outputs (on a device)
> are unregistered, to respond to the bus-protocol.  Are you saying that
> the XCS2-150-5 device was barely fast enough to meet 33MHz timing?
>
> Xilinx brazenly boasts that their Virtex family (the old 0.25micron
> family) supports PCI66MHz/64-bit.  Your experience suggests that
> while this can certainly be true, it's not an easily achievable
> target for someone not designing specifically for FPGA.
>
> Someone I know wants to develop a PCI-core for an in-house project.
> He threw around the idea of prototyping it on an FPGA-board.
> I advised him against it, simply because a lot of his design
> implementation would be governed by the FPGA's architectire
> (vs the actual production goal of a standard cell ASIC process.)
>
> I reasoned he'd be wasting a lot of dev time making the core
> work on an FPGA-device, i.e. wasting dev-time "designing for
> FPGA", instead of just designing for the final project goal.
>
> sorry if this is a redundant question...

--
--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: 37219
Subject: Re: 128-bit scrambling and CRC computations
From: kahhean@hotmail.com (Chua Kah Hean)
Date: 3 Dec 2001 22:52:39 -0800
Links: << >>  << T >>  << A >>
Hi all gurus out there,

First of all, a million thanks to Allan for the write-up.  It all
makes sense now.

Any way, I did some binary long division manually (word by word rather
than bit by bit) to have a feel of how the xor logic is generated.  It
becomes clear to me that whatever the input word length, the number of
bits that have to be "carried over" to the next word is only C=number
of CRC bits.   And these are the feedback bits to the small xor tree
in Allan's diagram.

If we can pipeline the input word, increasing the input word length
will not have any impact on the circuit speed.  This looks almost
magical to me.  :-)  But so far I am convinced it works.

By the way, is there any web site/book which have a list of such
interesting digital design problems?  I love brain teasers like this
(although I am lousy at solving them).

Thanks.

TA TA
kahhean

Article: 37220
Subject: How to increase clock skew for Spartan-II
From: kevinbraceusenet@hotmail.com (Kevin Brace)
Date: 3 Dec 2001 23:35:05 -0800
Links: << >>  << T >>  << A >>
I will like to know if there is a way to increase clock skew by about
1.0 ns through a .UCF file (User Constraint File).
I am having problems meeting Tsu (setup time), and adding 1.0ns of
clock skew won't totally solve my problem, but it will help.
I will like to add the clock skew through a .UCF file because the HDL
code has to be portable across different FPGA vendors (mainly Xilinx
and Altera).
The device I am using is Xilinx Spartan-II 150K system gate part
(XC2S150-5), and the software I am using is Xilinx ISE WebPack 4.1.




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

Article: 37221
Subject: Re: XC17S00A programmable as XC17S00 for 2 XC2Ss?
From: "Karl Olsen" <karl@micro-technic.com>
Date: Tue, 4 Dec 2001 10:06:54 +0100
Links: << >>  << T >>  << A >>
Utku Ozcan <ozcan@netas.com.tr> wrote in message
news:3C0B97EC.CF2A0C30@netas.com.tr...

> We need such a PROM that can program two Spartan-II
> XC2S50-5FG256Cs at the same time.
>
> XC2S50 has configuration file size of 559.200 bits.
> So we need a PROM of size of = 2 x 559.200 = 1.118.400
> bits.
>
> The devices I have found are
>
> XC17S00A 3.3V XC17S200A one time programmable
> XC17V00A 3.3V XC17V02 in system programmable
>
> The problem is, we need an OTP SPROM but our Data I/O
> Programmer device only supports XC17S00 and XC17S00XL
> devices but not XC17S00A devices.
>
> However, when I have looked at the datasheets of XC17S00/XL
> http://www.xilinx.com/support/programr/files/17s00.pdf
> and datasheet of XC17S00A http://www.xilinx.com/partinfo/ds078.pdf
> I see that the internal logic of these devices are the same.
> I haven't found any difference.
>
> XC17S00/XL family doesn't have any PROM that can hold two
> Spartan-II XC2S50 at the same time. On the other side
> Xilinx doesn't say that Spartan II devices can be programmed
> with XC17S00/XL PROMs.
>
> The reason why we look at XC17S00/XL devices for Spartan-II
> is that our Data I/O Programmer only supports XC17S00/XL
> devices.
>
> I have thought that XC17S00/XL in Data I/O Programmers are
> compatible with XC17S00A PROMs, therefore I can use XC17S00/XL
> mode in Data I/O Programmer to program XC17S00A PROMs.

Hi Utku,

I asked the same question to a Xilinx support person, and got the answer
that the programming algorithms for the XC17S00XL and the XC17S00A PROMs are
different.  You need a programmer that supports XC17S00A to program them.

Regards,
Karl Olsen




Article: 37222
Subject: Re: How to increase clock skew for Spartan-II
From: hamish@cloud.net.au
Date: 04 Dec 2001 11:34:38 GMT
Links: << >>  << T >>  << A >>
Kevin Brace <kevinbraceusenet@hotmail.com> wrote:
> I will like to know if there is a way to increase clock skew by about
> 1.0 ns through a .UCF file (User Constraint File).
> I am having problems meeting Tsu (setup time), and adding 1.0ns of
> clock skew won't totally solve my problem, but it will help.
> I will like to add the clock skew through a .UCF file because the HDL
> code has to be portable across different FPGA vendors (mainly Xilinx
> and Altera).
> The device I am using is Xilinx Spartan-II 150K system gate part
> (XC2S150-5), and the software I am using is Xilinx ISE WebPack 4.1.

Clock skew figures quoted by TRCE/Timing Analyzer are only maximum
values anyway -- the actual skew in the real silicon could be
anything from that value down to zero (perhaps even negative).
So even if you could add that skew, it would only add to the
maximum, not necessarily the actual.

You could daisy chain the global buffers or something like that.
You could use the phase shift if you had a Virtex-II.

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

Article: 37223
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: hamish@cloud.net.au
Date: 04 Dec 2001 11:42:52 GMT
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote:
> On the other hand, place and route algorithms are in a class of problems
> known as NP complete if my schooling has not failed me (or my memory).
> This means essentially that you can NEVER deterministically find the
> best solution to the problem for a realistic application given the state
> of technology in the foreseeable future. At least this is true until we
> are using Quantum computing which can explore all solution sets
> simultaneously. 

This may be true, but it says nothing of the ability of the open
source community to deliver a PAR tool equivalent in quality to
Xilinx's or Altera's. After all, neither Xilinx or Altera are
delivering a PAR tool which can deterministically find the
best solution, as far as I can tell :-)

Of course the chip vendors will always have the inside information
on the chip. In fact, they are the only ones with the information
on the chip presently, since they don't release enough details
for anyone else to create a bitstream.

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

Article: 37224
Subject: Re: What do you like/dislike about place and route tools?
From: hamish@cloud.net.au
Date: 04 Dec 2001 11:47:21 GMT
Links: << >>  << T >>  << A >>
John_H <johnhandwork@mail.com> wrote:
>   Nobody is doing "critical route" placement.

Good point. I had to do something like this by hand using guide files
etc earlier in the year. Really ugly, but the end result worked out
OK. Unfortunately, the guide files aren't compatible between 3.x and 4.x!

> With the proper P&R strategies, the silicon that's been designed to kick
> some serious butt will finally be able to do just that.  Having the P&R
> kick the engineer in the butt really needs to stop.

Well put.

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



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