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 28175

Article: 28175
Subject: Re: Question about programming xcv100
From: "Simon Bacon" <simonb@tile.demon.co.cuthis.uk.>
Date: Sun, 24 Dec 2000 08:06:52 -0000
Links: << >>  << T >>  << A >>
David

Is your 'cell' a few LUTs/FFs with unchanging routing?
If so, I believe the experts in the group can help
you on this.

Simon

> What I was planning on doing (correct me if i'm way out of line here,
> which is fairly possible) was taking each 'cell' on the fpga (in a
> given area, for example an area of 20 x 20 cells) then having some
> simple rules which i'd follow, deciding what the purpose of a given
> cell was to be (within the rules, eg only one output to drive a given
> line) then i'd take this meta design (arrived at through an evolving
> algorithm) convert it to the bitstreams and pass the bitstream to the
> chip using the xsload (comes with the Xess cdrom) where it would be
> evaluated. However i'd need to find out what each bit for a cell
> specified which I could then use to transfer my meta design to a
> bitstream - is it possible to get this info [i'm just a hobbyist, no
> danger of me seeking to get any competitive advantage over xilinx i
can
> assure you :-)]




Article: 28176
Subject: Re: really fast counter in SpartanXL?
From: "Simon Bacon" <simonb@tile.demon.co.cuthis.uk.>
Date: Sun, 24 Dec 2000 08:14:41 -0000
Links: << >>  << T >>  << A >>
Peter

What is the reference to your fast counter?  Didn't it
make special use of an XC4000 GCLK input buffer, the
fastest available buffer, or something like that?

/Simon

"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
news:3A453A6D.3A4D590A@xilinx.com...

> The counter that resolves the highest frequency is a simple ripple
counter,
> where only one flip-flop has to toggle at the max rate. I built a 420
MHz
> BCD-ripple counter 3 years ago, and will soon try to do an even GHz in
> Virtex-II.




Article: 28177
Subject: Re: Question about programming xcv100
From: Philip Freidin <philip@fliptronics.com>
Date: Sun, 24 Dec 2000 00:48:48 -0800
Links: << >>  << T >>  << A >>
On Sun, 24 Dec 2000 00:29:06 GMT, longwayhome@my-deja.com wrote:
>In article <3A45264E.F4FBE995@xilinx.com>,
>  peter.alfke@xilinx.com wrote:
>> David,
>> let me talk you out of what you seem to be trying.
>
>Oh dear :-)

Well, I wont try and talk you out of it, but I will try and save you some
time understanding your options.

First, permuting the bit stream directly (using an XC6200) has been done,
and there were some interesting results.

see  http://www.cogs.susx.ac.uk/users/adrianth/ade.html

>> Xilinx used to make the XC6200 chip that did not have multiple outputs
>> able to drive the same line, so it was bullet-proof, and it became the
>> darling of experimenters like you.
>> Unfortunately, XC6200 did not find a home in commercial applications,
>so
>> we stopped making it.
>
>Yes, someone recommended me to get one of those chips, however I
>learned you weren't producing them anymore (and didn't know why they
>had become so 'legendary' in this use anyway).
>
>> If you want to put evolving bitstreams on any Xilinx ( or Altera or
>Atmel)
>> FPGAs, don't do it !

Do it, but be really careful.

>What I was planning on doing (correct me if i'm way out of line here,
>which is fairly possible) was taking each 'cell' on the fpga (in a
>given area, for example an area of 20 x 20 cells) then having some
>simple rules which i'd follow, deciding what the purpose of a given
>cell was to be (within the rules, eg only one output to drive a given
>line) then i'd take this meta design (arrived at through an evolving
>algorithm) convert it to the bitstreams and pass the bitstream to the
>chip using the xsload (comes with the Xess cdrom) where it would be
>evaluated. However i'd need to find out what each bit for a cell
>specified which I could then use to transfer my meta design to a
>bitstream - is it possible to get this info [i'm just a hobbyist, no
>danger of me seeking to get any competitive advantage over xilinx i can
>assure you :-)]

What you do depends on how random/constrained you want the
primordial soup to be, how long it takes to create an individual,
and how long it takes to evaluate the individual.

First, the bitstream format is proprietory,and  Xilinx has given no
indication that this will change. (Others who have seen this
thread before (and before, and before) might think this is a
wondeful opportunity to restart this thread again. Please, as my
holiday wish, dont)

Since XC6200 is not readily available either, what that leaves
you are neat products like Virtex, which have a wonderful set
of features to play with.

So a typical Flow from a specification to an individual might be:

VHDL -> EDIF -> NCD -> Placed and routed NCD -> Bitstream.

For all the following proposals, you probably need to do things
to make sure your specification of the individual does not specify
anything illegal.

If time to create an individual is not an issue, have you individual
generator create VHDL.

All the following require less time to create an individual, but have
progressively more complex generator challenges :-)

Generate EDIF directly.

Generate unrouted NCD directly. Use a program called XDL which
is available from Xilinx, if you ask. You need to do quite a lot of work
to make this useable, but you do get full access to the chip's
capabilities.

Generate routed NCD directly. Use a program called XDL which
is available from Xilinx, if you ask. You need to do quite a lot of work
to make this useable, but you do get full access to the chip's
capabilities. Since you are skipping Place and route, this is faster
than the previous suggestion, but now P&R is your responsibility

Edit a P&R NCD with JBITS. This program was created by people
like you, for you. It is a Java interface to the bitstream. You use it
either to creat a bitstream from scratch, or to modify an existing
bitstream.

The FPGA editor program can be used to modify an NCD file, and
it can be run in batch mode. Theoretically you could create a base
individual, and create edit scripts to modify it.

>I didn't actually want to treat the bitstreams themselves as a piece
>of 'dna' to mutate/breed etc although now that you've mentioned that
>idea an XC6200 board would be a nice thing to have (if xilinx have any
>such boards lying around destined for wastage... :-)

This is what Adrian Thompson did
see  http://www.cogs.susx.ac.uk/users/adrianth/ade.html
and in particular:
  http://www.cogs.susx.ac.uk/users/adrianth/cacm99/paper.html


>Thanks for your warning though. Can you can help with that cell
>programming info, or suggest any other way of approaching this
>problem ? (i'm _really_ desperate to try this evolving hardware
>thing...)
>
>David
>

Here are some ideas for much easier stuff than above that you might
want to consider, as a way to get started, and maybe get some
useful results with very fast generation.

1) Create a design that uses the LUTs in dual port RAM mode, and
connect them up in some sort of mesh, with some feedback too.
Use only one read port for all the logic. I.e. each pair of LUTs that
run as 16 x 1 DP RAM, use the read port for building your individual.
Connect all the write ports to the individual generator. For this
topology, the interconnect is static, but you can vary the gate at
an extremely fast rate.

2) Like 1, but add some flipflops to the soup.

3) Like 1 or 2, but allocate some LUTs to implement some muxes,
and this then gives you some limited ability to change the routing.

4) More of the same, add in block RAMs (maybe in dual port mode)

All of these can be done while avoiding the disaster of creating
illegal bitstreams. With a careful design, you may be able to create
individuals in as little as a micro second. If you can test them in the
same amount of time, you could evolve 500,000 individuals per
second, which might make up for the constraints of the soup.

Have fun.

Philip Freidin



Philip Freidin
Fliptronics

Article: 28178
Subject: Re: Question about programming xcv100
From: Neil Franklin <neil@franklin.ch.remove>
Date: 24 Dec 2000 17:38:09 +0100
Links: << >>  << T >>  << A >>
Philip Freidin <philip@fliptronics.com> writes:

> On Sun, 24 Dec 2000 00:29:06 GMT, longwayhome@my-deja.com wrote:
> >In article <3A45264E.F4FBE995@xilinx.com>,
> >  peter.alfke@xilinx.com wrote:
> >> David,
> >> let me talk you out of what you seem to be trying.
> >
> >Oh dear :-)
>
> Well, I wont try and talk you out of it, but I will try and save you some
> time understanding your options.

And I will add to that.


> >> If you want to put evolving bitstreams on any Xilinx ( or Altera or
> >Atmel)
> >> FPGAs, don't do it !
>
> Do it, but be really careful.

Or have a tool be carefull for you. Written by someone who does know
what the bitstream does.


> Edit a P&R NCD with JBITS. This program was created by people
> like you, for you. It is a Java interface to the bitstream. You use it
> either to creat a bitstream from scratch, or to modify an existing
> bitstream.

Or even uses Xilinx own prefab FPGA evolver in the JBits package.

From: <installdir>/JBits2.5/ReadMe.html (The JBits 2.5 SDK for Virtex)

--------------- begin quote
GeneticFPGA

GeneticFPGA, is a Java-based tool for evolving circuits on Xilinx
Virtex? FPGAs or on the JBits Device Simulator. Using an evolutionary
algorithm, the system mutates a bitstream to create a circuit. The
user specifies a fitness function that measures how well the circuit
performs, along with some stimulus and expected output. The system
mutates the bitstream to reduce the error between the actual output
and the expected output. The design process is a bit non-traditional.
Whereas a designer typically creates a circuit by assembling known
structures, here a designer specifies desired behavior and lets the
system construct the solution.
--------------- end quote

And yes, the question mark is in the original text.


If you want to go this way, send a mail to jbits@xilinx.com to order
your copy (you recieve URL and password by reply email).


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic

Article: 28179
Subject: Re: Verilog or VHDL
From: Srinivasan Venkataramanan <srinivasan_v@my-deja.com>
Date: Sun, 24 Dec 2000 18:37:57 GMT
Links: << >>  << T >>  << A >>
Hi,

In article <slrn94bb9q.jju.kenkovaa@gamma.hut.fi>,
  kenkovaa@gamma.hut.fi (Kim Gunnar Enkovaara) wrote:
> On Mon, 18 Dec 2000 02:39:05 GMT, bobdittmar@my-deja.com wrote:
>

<SNIP>

> Without PLI Verilog is quite difficult language to use for really
> complex behavioral models. The Verilog language itself is quite
> restricted, for example file i/o is poor compared to VHDL (altough
> it's easier to use in Verilog). Also without real data types complex
> behavioral models are not fun thing to do.
>

  Just wanted to comment that Verilog indeed has "real data type" and I
have used it to model ADC, DAC etc. at Behavioural level. Nevertheless
I agree with you STRONGLY that VHDL is way ahead in terms of its
Behavioural modelling capabilities (compared to Verilog).

> For verification I would suggest new verification languages (Vera,
> e). I have used Vera quite extensivly and wouldn't go back easily to
> HDL languages in testbenches. I can't even think of writing 30-40k
> lines of complex TB code in some HDL language :) Object orientation
> speeds up the TB-design considerably.
>

  Interesting opinion, Thanks for sharing that :-) But how much  is
this difficult, do you think, that for a Hardware Guy to understand
this OO stuff. I attended a course on VERA, found it nice, but was
having hard time in coding with it - I must admit that I didn't spend
enough time with it (and have just changed the company where there is
no VERA yet, so can't continue (:- ) and was kind of "convinced by
others that OO stuff is difficult for H/W guys".


Regards,
Srini

--
Srinivasan Venkataramanan
ASIC Design Engineer
Chennai, India


Sent via Deja.com
http://www.deja.com/

Article: 28180
Subject: Re: driving color VGA from FPGA ??
From: jdhduighejhvkxjcn <hiuweurowej@hehe.com>
Date: Sun, 24 Dec 2000 13:24:50 -0800
Links: << >>  << T >>  << A >>
Conexant (formerly Rockwell, who bought out Brooktree) also makes some
RAMDACs and video capture ICs, too.

> IBM used to make some nice RAMDACs. I just checked out
> www.chips.ibm.com and it seems that they are not making them anymore.
> Another vendor is Analog Devices.

Article: 28181
Subject: Actel DeskTop Design Tool Set
From: pinhas@my-deja.com
Date: Mon, 25 Dec 2000 08:55:27 GMT
Links: << >>  << T >>  << A >>
Does somebody know this free software conatin any static timing
analyzer.


Sent via Deja.com
http://www.deja.com/

Article: 28182
Subject: Re: Verilog or VHDL
From: kenkovaa@gamma.hut.fi (Kim Gunnar Enkovaara)
Date: 25 Dec 2000 08:59:24 GMT
Links: << >>  << T >>  << A >>
On Sun, 24 Dec 2000 18:37:57 GMT, Srinivasan Venkataramanan wrote:
>> it's easier to use in Verilog). Also without real data types complex
>> behavioral models are not fun thing to do.
>>
>
>  Just wanted to comment that Verilog indeed has "real data type" and I
>have used it to model ADC, DAC etc. at Behavioural level. Nevertheless

I meant with real data types possibility to define own data types
etc.

>> For verification I would suggest new verification languages (Vera,
>> e). I have used Vera quite extensivly and wouldn't go back easily to
>
>  Interesting opinion, Thanks for sharing that :-) But how much  is
>this difficult, do you think, that for a Hardware Guy to understand
>this OO stuff. I attended a course on VERA, found it nice, but was
>having hard time in coding with it - I must admit that I didn't spend

For normal small testbenches OO is not needed and the code is quite like
Verilog or C with some additions. But the possibility to use OO
abstraction enables huge possibilities in TB design. I think the
biggest step is to just start using Vera (possibly needs some forcing
from the management, nobody wants to spend time with new tool usually)
It takes few weeks to learn the new language propely, but after that
the gains can be huge.

I admit that this is difficult for current generation of HW-engineers,
but the ones graduating now have experience in Java/C++ and can easily
code Vera. At least I see that OO based testbenches are the future. It
is just too difficult to manage these big testbenches in HDL languages.

>enough time with it (and have just changed the company where there is
>no VERA yet, so can't continue (:- ) and was kind of "convinced by
>others that OO stuff is difficult for H/W guys".

I think the important factor is that there is someone with SW
experience doing the basic design of the TB, at least in the
beginning. I designed one of our TB structures and it was quite easy
for HW-designers to code parts to the framework when they saw how
everyting was attached together.

When the verification effort starts to be 60-70% of the whole
effort I don't think it is a bad idea to hire pure SW guy to the
team to do TB code etc. At least SW guy has the needed experience to
design propely those big testbenches possibly using UML and other SW
design tools. For example I'm now thinking about distributed testbenches
where each chip in a big chipset (and it's testbench) is running on
different machine and the testbenches are communicating all trough
network with eachother. That is one way of getting more speed to
the simulations. But the code of doing these kinds of things starts to
be quite complex but can be done in Vera.

-- 
=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Iirislahdentie 47 E | IRC: embo            | curved-space fault in
02230 Espoo,Finland |                      | write-only file system

Article: 28183
Subject: Re: Actel DeskTop Design Tool Set
From: rk <stellare@nospamplease.erols.com>
Date: Mon, 25 Dec 2000 09:18:27 -0500
Links: << >>  << T >>  << A >>
pinhas@my-deja.com wrote:
 
> Does somebody know this free software conatin any static timing
> analyzer.

Yes, it's in Designer.

Article: 28184
Subject: Re: Synplicity and multiple input IOB flops...how to specify which one goes in the IOB?
From: "Austin Franklin" <austin@darkroo98m.com>
Date: 25 Dec 2000 14:35:41 GMT
Links: << >>  << T >>  << A >>
> Ah, you are lucky! You have a _slow_ clock. I always seem to have a fast
clock and then smoe faster... ;-)

Ah, that wasn't done by 'luck' it was the result of good 'engineering'!

;-)

BTW, it's only recently that 16.666MHz is considered a 'slow' clock!  Hell,
60ns is an eternity these days!



Article: 28185
Subject: Re: Question about programming xcv100
From: longwayhome@my-deja.com
Date: Mon, 25 Dec 2000 19:38:17 GMT
Links: << >>  << T >>  << A >>
In article <6ur92xsrke.fsf@chonsp.franklin.ch>,
  Neil Franklin <neil@franklin.ch.remove> wrote:
> Or even uses Xilinx own prefab FPGA evolver in the JBits package.

Hello everyone, and thanks for all the helpful responses.
I've downloaded the jbits package and java 2 sdk from sun, and
everything went fine (the jbits package even comes with a very
efficient genetic algorithm already included with the evolver mechanism
which is great! (you can of course substitute that with your own
algorithm object if you want to)).

My only problem now is that to use the genetic evolution classes (and
any other classes for writing to the virtex device) you need to have a
null bitstream file (to guarantee that you don't damage the device -
the evolution classes look after that for you once it starts, but you
need to have it in a safe state to begin with). The jbits package came
with null bit files for the xcv300, 800 and 1000, unfortunately i have
an xcv100 board (on which i've already run xess's test program, so im
not sure what state the current gates etc are left in although thats
probably not so important).

According to the documentation "the null bitstream specifies a circuit
with all the fpga resources turned off and unconnected. This bitstream
is typically generated by the Xilinx Foundation/Alliance tools and is
then initialized to a null state using the MakeNullBs program".

Am I right in thinking that if I write a small jbits program to read
the current configuration and then run MakeNullBs [comes with jbits] on
the resulting bitstream I get a 'null bitstream' ? [I don't have
Foundation/Alliance btw]. MakeNullBs takes an input bitstream and
returns an output one, but other than that its documentation is non
existant that I can find.

Thanks again and seasons greetings! :-)

David



Sent via Deja.com
http://www.deja.com/

Article: 28186
Subject: Newbie question on clock timing generation
From: blueflyer@my-deja.com
Date: Tue, 26 Dec 2000 07:35:39 GMT
Links: << >>  << T >>  << A >>
Merry X'mas!! Unfortunated, I am back to work.

I have a question and will appreciate anybody who can help clarify it:

- I need to generate a clock for a circuit with many subcirccuits in it.

- The circuit is driven by a master clock (Clk).

- Each subcircuit has it's own clock derived from the master clock,
and each clock has different clock rate (say Clk/2, Clk/4, Clk/5,
Clk/7).


- Each subcircuit is actived at different time and at different Clk
edges (say the first subcircuit is activated at 12*Clk'rising_edge, done
at 19*Clk'falling_edge. 20*Clk'falling_edge starts the second subcircuit
and deactivated at 37*Clk'rising_edge......)

- To keep the power low, the clocks for each subcircuit may be gated.


Now the question is how to implement this in VHDL and suitable for
synthesis? I have tried two ways

(1) Having many counters and output appropriate timing when the counters
count to a certain number. This require much more thinking to come up
with appropriate setup for the counters. It generates couple errors when
I tried to synthesize the circuit even it simulated OK. Haven't tried to
solve the problem.

(2) Using state machine, change state at Clk'event and output
appropriate signals at the right state. This seems more friendlier to
the synthesis tool (it didn't complain anything) and it is much easier.
But the problem is that it has many states and it seems to me that this
way is too bruteforce and very tedious.


So the question is which way is better? I am targeting at FPGA at this
monent and pretty soon mitigration to ASIC is very necessary.

TIA


Sent via Deja.com
http://www.deja.com/

Article: 28187
Subject: Re: really fast counter in SpartanXL?
From: "Kevin Neilson" <kmneilson@earthlink.net>
Date: Wed, 27 Dec 2000 05:24:51 GMT
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.

------=_NextPart_000_0153_01C06F8A.7027CB40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Theron,
I recently made a 16-bit counter for Virtex using Johson rings that was =
twice as fast as the standard carry-chain based counter.  The counter =
was constructed of a 4-bit Johnson Ring counter appended to a 12-bit =
conventional counter.  It used SRLs, but you can to the same thing with =
flops.  It may not be as fast as a ripple counter but it's synchronous =
and should run at the speed you need.

The reason the Johnson rings are so fast is that there are NO LUTs =
between the flop outputs and flop inputs.  You can't get any faster than =
that for synchronous circuits.  Here's what you do.  The LSB is a Johson =
ring (shift register with one end tied to the other in a ring) with two =
flops.  One has a reset value of 1, the other zero.  They just trade the =
1 and 0. Bit 1 is made of a ring of 4 flops, with the reset values =
'0011'.  You can see that the first flop in the ring will change every =
2nd cycle.  Bit 2 is made of 8 flops, with reset values '00001111' and =
bit 3 of 16 flops with reset values '0000000011111111'.  Using the first =
flop in each of the four rings, you have a 4-bit counter.  There is an =
XCell article that relates to this.

This 4-bit counter operates at the highest possible synchronous speed =
because there's no logic between any of the flops, just routing.

Now you can append a conventional 12-bit counter (with carry chain) to =
this counter.  The 12-bit counter will have a clock enable that is only =
enabled on the cycle when the 4-bit counter changes from '1111' to =
'0000'.  Actually it would be faster to pipeline this:  you would have a =
flop that would go high when the 4-bit counter was '1110' and that flop =
would be used as a clock enable for the 12-bit counter.  That would =
require one level of logic.  This is probably your critical path.

If you don't want even one level of logic, you can make a 5th Johnson =
ring that has 16 flops and upon reset only the first one is set.  This =
'1' travels around the ring and is used as a clock enable for the 12-bit =
counter every 16th cycle.

The 12-bit counter does indeed require a carry chain, but it is not your =
critical path because the registers in the 12-bit counter only change =
every 16 cycles so are 16-cycle multicycle paths.  The carry chain has =
16 cycles to propagate.  You just need to make sure to inform the =
synthesizer of that fact.  You may be able to use instead a 3-bit =
Johson-ring counter and a 13-bit conventional counter.

It seems like this should actually match the speed of a ripple, but in =
any case you should make your 208MHz goal and you will avoid routing =
clocks and will have a synchronous design.  If you use a ripple, you =
will have to shut it off to allow it to settle before reading it or =
transferring it to a holding register.

-Kevin Neilson, IDS
  Peter Alfke wrote in message <3A3814B5.660E2B3F@xilinx.com>...
  Theron,=20
  you can easily achieve twice that speed. I did that 2 years ago when =
designing a 400-MHz frequency counter, as described in XCell=20
  http://www.xilinx.com/xcell/xl32/xl32_47.pdf=20
  That counter had to be decimal, which makes things a bit more =
complicated.=20

  In your case, just stay away from global clocks. Route the input clock =
signal to the clock input of a single CLB flip-flop ( best placed on the =
left edge of the device.) Make it toggle, using a tight feedback loop =
(<2ns)=20
  Then use this Q as a clock for the next CLB, configured as a 2-bit =
counter, since the two flip-flops have a common clock. Use the highest Q =
as clock for the nect CLB, etc.=20
  That gives you a ripple counter with the best possible input =
resolution ( yes, and an awful ripple delay.)=20
  400 MHz should be no problem.=20
  Use a small housekeeping state machine to enable/disable the counter =
through the asynchronous ( or synchronous) clear of the front-end =
flip-flop, and some time later clear all bits prior to the next count =
cycle.=20

  Itmay be heresy to a computer designer, but it works beautifully.=20

  Peter Alfke, Xilinx Applications=20
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
  Theron Hicks wrote:=20

    Can anyone give me the "best" way to implement a _fast_ counter in a =

    SpartanXL design?  I need a 16 bit counter with enable and =
reset.clock=20
    on negative edge preferred but not critical.  I don't need the =
output to=20
    be synchronous because I am counting to measure pulse width so I can =

    wait for the final result to ripple through to the output.  The =
_only_=20
    factor of importance is _speed_.  Should I use logiBLOX or should I=20
    write my owm or should I forcibly implement it using some unknown =
(to=20
    me) tool?  I need to get up to 204.8MHz toggle frequency.  The =
output in=20
    counts will be latched after the pulse is completed and the =
resulting=20
    count values will be passed through a tri-state output of some sort. =

    Thanks,=20
    Theron J. Hicks


------=_NextPart_000_0153_01C06F8A.7027CB40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type><!doctype html public "-//w3c//dtd html 4.0 =
transitional//en">
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Theron,</FONT></DIV>
<DIV><FONT size=3D2>I recently made a 16-bit counter for Virtex using =
Johson rings=20
that was twice as fast as the standard carry-chain based counter.&nbsp; =
The=20
counter was constructed of a 4-bit Johnson Ring counter appended to a =
12-bit=20
conventional counter.&nbsp; It used SRLs, but you can to the same thing =
with=20
flops.&nbsp; It may not be as fast as a ripple counter but it's =
synchronous and=20
should run at the speed you need.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>The reason the Johnson rings are so fast is that =
there are NO=20
LUTs between the flop outputs and flop inputs.&nbsp; You can't get any =
faster=20
than that for synchronous circuits.&nbsp; Here's what you do.&nbsp; The =
LSB is a=20
Johson ring (shift register with one end tied to the other in a ring) =
with two=20
flops.&nbsp; One has a reset value of 1, the other zero.&nbsp; They just =
trade=20
the 1 and 0. Bit 1 is made of a ring of 4 flops, with the reset values=20
'0011'.&nbsp; You can see that the first flop in the ring will change =
every 2nd=20
cycle.&nbsp; Bit 2 is made of 8 flops, with reset values '00001111' and =
bit 3 of=20
16 flops with reset values '0000000011111111'.&nbsp; Using the first =
flop in=20
each of the four rings, you have a 4-bit counter.&nbsp; There is an =
XCell=20
article that relates to this.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>This 4-bit counter operates at the highest possible=20
synchronous speed because there's no logic between any of the flops, =
just=20
routing.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Now you can append a conventional 12-bit counter =
(with carry=20
chain) to this counter.&nbsp; The 12-bit counter will have a clock =
enable that=20
is only enabled on the cycle when the 4-bit counter changes from '1111' =
to=20
'0000'.&nbsp; Actually it would be faster to pipeline this:&nbsp; you =
would have=20
a flop that would&nbsp;go high when the 4-bit counter was '1110' and =
that flop=20
would be used as a clock enable for the 12-bit counter.&nbsp; That would =
require=20
one level of logic.&nbsp; This is probably your critical =
path.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>If you don't want even one level of logic, you can =
make a 5th=20
Johnson ring that has 16 flops and upon reset only the first one is =
set.&nbsp;=20
This '1' travels around the ring and is used as a clock enable for the =
12-bit=20
counter every 16th cycle.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>The 12-bit counter does indeed require a carry =
chain, but it=20
is not your critical path because the registers in the 12-bit counter =
only=20
change every 16 cycles so are 16-cycle multicycle paths.&nbsp; The carry =
chain=20
has 16 cycles to propagate.&nbsp; You just need to make sure to inform =
the=20
synthesizer of that fact.&nbsp; You may be able to use instead a 3-bit=20
Johson-ring counter and a 13-bit conventional counter.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>It seems like this should actually match the speed =
of a=20
ripple, but in any case you&nbsp;should make your 208MHz goal and you =
will avoid=20
routing clocks and will have a synchronous design.&nbsp; If you use a =
ripple,=20
you will have to shut it off to allow it to settle before reading it or=20
transferring it to a holding register.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>-Kevin Neilson, IDS</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV>Peter Alfke <PETER.ALFKE@XILINX.COM>wrote in message &lt;<A=20
  =
href=3D"mailto:3A3814B5.660E2B3F@xilinx.com">3A3814B5.660E2B3F@xilinx.com=
</A>&gt;...</DIV>Theron,=20
  <BR>you can easily achieve twice that speed. I did that 2 years ago =
when=20
  designing a 400-MHz frequency counter, as described in XCell <BR><U><A =

  =
href=3D"http://www.xilinx.com/xcell/xl32/xl32_47.pdf">http://www.xilinx.c=
om/xcell/xl32/xl32_47.pdf</A></U>=20

  <P>That counter had to be decimal, which makes things a bit more =
complicated.=20
  <P>In your case, just stay away from global clocks. Route the input =
clock=20
  signal to the clock input of a single CLB flip-flop ( best placed on =
the left=20
  edge of the device.) Make it toggle, using a tight feedback loop =
(&lt;2ns)=20
  <BR>Then use this Q as a clock for the next CLB, configured as a 2-bit =

  counter, since the two flip-flops have a common clock. Use the highest =
Q as=20
  clock for the nect CLB, etc. <BR>That gives you a ripple counter with =
the best=20
  possible input resolution ( yes, and an awful ripple delay.) <BR>400 =
MHz=20
  should be no problem. <BR>Use a small housekeeping state machine to=20
  enable/disable the counter through the asynchronous ( or synchronous) =
clear of=20
  the front-end flip-flop, and some time later clear all bits prior to =
the next=20
  count cycle.=20
  <P>Itmay be heresy to a computer designer, but it works beautifully.=20
  <P>Peter Alfke, Xilinx Applications=20
  =
<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D <BR>Theron Hicks wrote: =

  <BLOCKQUOTE TYPE=3D"CITE">Can anyone give me the "best" way to =
implement a=20
    _fast_ counter in a <BR>SpartanXL design?&nbsp; I need a 16 bit =
counter with=20
    enable and reset.clock <BR>on negative edge preferred but not=20
    critical.&nbsp; I don't need the output to <BR>be synchronous =
because I am=20
    counting to measure pulse width so I can <BR>wait for the final =
result to=20
    ripple through to the output.&nbsp; The _only_ <BR>factor of =
importance is=20
    _speed_.&nbsp; Should I use logiBLOX or should I <BR>write my owm or =
should=20
    I forcibly implement it using some unknown (to <BR>me) tool?&nbsp; I =
need to=20
    get up to 204.8MHz toggle frequency.&nbsp; The output in <BR>counts =
will be=20
    latched after the pulse is completed and the resulting <BR>count =
values will=20
    be passed through a tri-state output of some sort.=20
    <P>Thanks, <BR>Theron J. =
Hicks</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0153_01C06F8A.7027CB40--


Article: 28188
Subject: Re: Question about programming xcv100
From: "Domagoj" <domagoj@engineer.com>
Date: Wed, 27 Dec 2000 06:35:26 +0100
Links: << >>  << T >>  << A >>
Hi Philip,

Philip Freidin <philip@fliptronics.com> wrote in message
news:2sbb4t44310hftg2j35agsc59aq7ma26du@4ax.com...
> On Sun, 24 Dec 2000 00:29:06 GMT, longwayhome@my-deja.com wrote:
> >In article <3A45264E.F4FBE995@xilinx.com>,
> Edit a P&R NCD with JBITS. This program was created by people
> like you, for you. It is a Java interface to the bitstream. You use it
> either to creat a bitstream from scratch, or to modify an existing
> bitstream.

    Do you maybe know the price of JBITS package ? Any discounts for
universities ?
I haven't found much info on Xilinx site about that sw.
Thanks.

regards,
-------------------------------------------
-             Domagoj              -
- Domagoj@engineer.com -
-------------------------------------------




Article: 28189
Subject: Re: Newbie question on clock timing generation
From: Greg Neff <gregneff@my-deja.com>
Date: Wed, 27 Dec 2000 17:52:30 GMT
Links: << >>  << T >>  << A >>
In article <929hob$t60$1@nnrp1.deja.com>,
  blueflyer@my-deja.com wrote:
> Merry X'mas!! Unfortunated, I am back to work.
>
> I have a question and will appreciate anybody who can help clarify it:
>
> - I need to generate a clock for a circuit with many subcirccuits in
it.
>
> - The circuit is driven by a master clock (Clk).
>

Right. You drive *all* flip-flops in the FPGA directly from this master
clock, using global clock routing resources.

> - Each subcircuit has it's own clock derived from the master clock,
> and each clock has different clock rate (say Clk/2, Clk/4, Clk/5,
> Clk/7).
>

Wrong!  Don't do this.  Instead, use the divider outputs as clock
enables for the flip-flops.

> - Each subcircuit is actived at different time and at different Clk
> edges (say the first subcircuit is activated at 12*Clk'rising_edge,
done
> at 19*Clk'falling_edge. 20*Clk'falling_edge starts the second
subcircuit
> and deactivated at 37*Clk'rising_edge......)

You can use the rising and falling edges of the master clock, if
necessary.

>
> - To keep the power low, the clocks for each subcircuit may be gated.
>

No, they may not be gated.  Unless you know exactly what you are doing,
and the internal architecture of the FPGA, you *must* clock all flip-
flops directly from global clock nets.  No gates.


> Now the question is how to implement this in VHDL and suitable for
> synthesis?

Don't bother.  You are trying do do something in an FPGA that is not
supposed to be done, and is contrary to good digital and FPGA design
practices.

(snip)

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com
http://www.deja.com/

Article: 28190
Subject: Re: evolving bitstreams
From: Phil James-Roxby <phil.james-roxby@xilinx.com>
Date: Wed, 27 Dec 2000 10:58:29 -0700
Links: << >>  << T >>  << A >>
Ben Franchuk wrote:
> 
> I don't think any kind of evolving is possible in the line of digital
> circuits in standard logic.Comparing FPGA's with carbon-based-logic is
> like comparing Apples and Turnips. The closest I can see something is
> with cellular logic like "life".
> Ben.

Think of evolution as just a form of optimization, and you can begin to
see why people see this as attractive.  If you can either filter out
illegal configurations, or as others do, arrange evolution in such a way
that they never arise, you have quite an interesting system, generating
a circuit from a sloppy specification of its behaviour.  Whether it
could ever grace the dizzy heights of synthesis from an HDL in terms of
complexity and QOR, who knows.  
I echo most of the sentiments in this thread, I suggest the original
poster (Dave?) talk to us in the JBits group, as we have plenty of stuff
to help him out.
Phil
-- 
---------------------------------------------------------------------
 __
/ /\/  Dr Phil James-Roxby         Direct Dial: 303-544-5545
\ \    Staff Software Engineer     Fax: Unreliable use email :-)
/ /    Loki/DARPA                  Email: phil.james-roxby@xilinx.com
\_\/\  Xilinx Boulder                 
---------------------------------------------------------------------

Article: 28191
Subject: Re: really fast counter in SpartanXL?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 27 Dec 2000 12:40:20 -0800
Links: << >>  << T >>  << A >>


Simon Bacon wrote:

> Peter
>
> What is the reference to your fast counter?  Didn't it
> make special use of an XC4000 GCLK input buffer, the
> fastest available buffer, or something like that?
>

http://www.xilinx.com/xcell/xl32/xl32_47.pdf

That counter had to be decimal, which makes things a bit more complicated.

In your case, just stay away from global clocks. Route the input clock
signal to the clock input of a single CLB flip-flop ( best placed on the
left edge
of the device.)
Make it toggle, using a tight feedback loop (<2ns)
Then use this Q as a clock for the next CLB, configured as a 2-bit
counter, since the two flip-flops have a common clock. Use the highest Q as
clock for the
nect CLB, etc.
That gives you a ripple counter with the best possible input
resolution ( yes, and an awful ripple delay.)
 400 MHz should be no problem.
Use a small housekeeping state machine to enable/disable the counter
through the asynchronous ( or synchronous) clear of the front-end
flip-flop,
and some time later clear all bits prior to the next count cycle.

     It may be heresy to a computer designer, but it works beautifully.

     Peter Alfke, Xilinx Applications


Article: 28192
Subject: Re: Question about programming xcv100
From: "Delon Levi" <delon.levi@xilinx.com>
Date: Wed, 27 Dec 2000 12:46:07 -0800
Links: << >>  << T >>  << A >>

The XC6200 was the first FPGA used to evolve circuits primarily because the
hardware was designed so that random bistreams would not cause contention,
which could destroy the chip.  Using a slighly modified process, we in the
JBits group have been evolving digital circuits on mainstream devices like
the Xilinx Virtex series for several years.  Instead of protecting against
contention at a hardware level, we protect against it using software.
Random bitstreams are still generated, but they are contstrained to only
generate non-contentious circuits.

If anyone is interested in finding out more, there is an evolvable hardware
toolkit in the JBits software.  You can obtain the software by sending a
request to JBits@xilinx.com  You can also read some papers that explain the
process in more detail:
http://www.io.com/~guccione/Papers/Papers.html

Delon


"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
news:3A45264E.F4FBE995@xilinx.com...
> David,
> let me talk you out of what you seem to be trying.
> The vast majority of the bits in the bitstream has a specific function,
> activating a pass transistor, controlling a multiplexer, driving a metal
> line etc. ( A few bits are just left-over fill bits, but only a few)
> If you start "evolving" bitstreams, you will most likely create massive
> contention on the chip, i.e. two opposite signals driving the same piece
> of metal. Although the individual contention current may be just a few mA,
> multiple thousands can literally melt down the plastic package and destroy
> the chip.
>
> Xilinx used to make the XC6200 chip that did not have multiple outputs
> able to drive the same line, so it was bullet-proof, and it became the
> darling of experimenters like you.
> Unfortunately, XC6200 did not find a home in commercial applications, so
> we stopped making it.
>
> If you want to put evolving bitstreams on any Xilinx ( or Altera or Atmel)
> FPGAs, don't do it !
> I copied Delon Levi here at Xilinx who may have additional thoughts.
>
> Peter Alfke, Xilinx Applications
> ================================
>
> longwayhome@my-deja.com wrote:
>
> > Hi
> > I bought an xsv100 board from Xess, which has a Xilinx xcv100 chip on
> > it. With the board came a utility which can send compiled bitstreams to
> > the chip. I'd like to manually generate the bitstreams though, rather
> > than compile them from a vhdl spec though, as my intention is to
> > program it using evolutionary algorithms and I think this would be
> > easier and faster than actually generating vhdl and compiling that then
> > sending that to the chip.
> >
> > Does anyone know where I can find a spec which would show exactly how
> > the bitstreams are interpreted by xcv100 ? I've already had an
> > unsuccessfull look at the Xilinx site (but i've had problems finding
> > what i want there before...)
> >
> > I'm a complete beginner at this, all advice greatfully accepted.
> >
> > Thanks
> >
> > David
> >
> > Sent via Deja.com
> > http://www.deja.com/
>



Article: 28193
Subject: Re: Newbie question on clock timing generation
From: blueflyer@my-deja.com
Date: Wed, 27 Dec 2000 20:52:44 GMT
Links: << >>  << T >>  << A >>
Greg,

I already realized that gated clock is not good practice in FPGA. My
question is how can we clock two subcircuit with different rates if all
the FFs are driven by the same Master clock? Say I have two subcircuits,
one is clocked at Clk_master/3, and the other Clk_master/2.

Thanks.


In article <92da8r$jfj$1@nnrp1.deja.com>,
  Greg Neff <gregneff@my-deja.com> wrote:
> In article <929hob$t60$1@nnrp1.deja.com>,
>   blueflyer@my-deja.com wrote:
> > Merry X'mas!! Unfortunated, I am back to work.
> >
> > I have a question and will appreciate anybody who can help clarify
it:
> >
> > - I need to generate a clock for a circuit with many subcirccuits in
> it.
> >
> > - The circuit is driven by a master clock (Clk).
> >
>
> Right. You drive *all* flip-flops in the FPGA directly from this
master
> clock, using global clock routing resources.
>
> > - Each subcircuit has it's own clock derived from the master clock,
> > and each clock has different clock rate (say Clk/2, Clk/4, Clk/5,
> > Clk/7).
> >
>
> Wrong!  Don't do this.  Instead, use the divider outputs as clock
> enables for the flip-flops.
>
> > - Each subcircuit is actived at different time and at different Clk
> > edges (say the first subcircuit is activated at 12*Clk'rising_edge,
> done
> > at 19*Clk'falling_edge. 20*Clk'falling_edge starts the second
> subcircuit
> > and deactivated at 37*Clk'rising_edge......)
>
> You can use the rising and falling edges of the master clock, if
> necessary.
>
> >
> > - To keep the power low, the clocks for each subcircuit may be
gated.
> >
>
> No, they may not be gated.  Unless you know exactly what you are
doing,
> and the internal architecture of the FPGA, you *must* clock all flip-
> flops directly from global clock nets.  No gates.
>
> > Now the question is how to implement this in VHDL and suitable for
> > synthesis?
>
> Don't bother.  You are trying do do something in an FPGA that is not
> supposed to be done, and is contrary to good digital and FPGA design
> practices.
>
> (snip)
>
> --
> Greg Neff
> VP Engineering
> *Microsym* Computers Inc.
> greg@guesswhichwordgoeshere.com
>
> Sent via Deja.com
> http://www.deja.com/
>


Sent via Deja.com
http://www.deja.com/

Article: 28194
Subject: Re: Newbie question on clock timing generation
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 27 Dec 2000 13:35:03 -0800
Links: << >>  << T >>  << A >>
You route the common clock to all flip-flops.
Then you design a state machine that generates clock enable signals
that you route to the appropriate flip-flops' CE inputs..
For example, a CE signal that is High for one out of three clock periods
enables your CLK/3 flip-flops.

Such state machines ( you might also call them counters )
can easily be designed with a few CLBs.
Really very big and fancy ones can be designed with BlockRAM.

Peter Alfke, Xilinx Applications
=================================================
blueflyer@my-deja.com wrote:

> Greg,
>
> I already realized that gated clock is not good practice in FPGA. My
> question is how can we clock two subcircuit with different rates if all
> the FFs are driven by the same Master clock? Say I have two subcircuits,
> one is clocked at Clk_master/3, and the other Clk_master/2.
>
> Thanks.
>
> In article <92da8r$jfj$1@nnrp1.deja.com>,
>   Greg Neff <gregneff@my-deja.com> wrote:
> > In article <929hob$t60$1@nnrp1.deja.com>,
> >   blueflyer@my-deja.com wrote:
> > > Merry X'mas!! Unfortunated, I am back to work.
> > >
> > > I have a question and will appreciate anybody who can help clarify
> it:
> > >
> > > - I need to generate a clock for a circuit with many subcirccuits in
> > it.
> > >
> > > - The circuit is driven by a master clock (Clk).
> > >
> >
> > Right. You drive *all* flip-flops in the FPGA directly from this
> master
> > clock, using global clock routing resources.
> >
> > > - Each subcircuit has it's own clock derived from the master clock,
> > > and each clock has different clock rate (say Clk/2, Clk/4, Clk/5,
> > > Clk/7).
> > >
> >
> > Wrong!  Don't do this.  Instead, use the divider outputs as clock
> > enables for the flip-flops.
> >
> > > - Each subcircuit is actived at different time and at different Clk
> > > edges (say the first subcircuit is activated at 12*Clk'rising_edge,
> > done
> > > at 19*Clk'falling_edge. 20*Clk'falling_edge starts the second
> > subcircuit
> > > and deactivated at 37*Clk'rising_edge......)
> >
> > You can use the rising and falling edges of the master clock, if
> > necessary.
> >
> > >
> > > - To keep the power low, the clocks for each subcircuit may be
> gated.
> > >
> >
> > No, they may not be gated.  Unless you know exactly what you are
> doing,
> > and the internal architecture of the FPGA, you *must* clock all flip-
> > flops directly from global clock nets.  No gates.
> >
> > > Now the question is how to implement this in VHDL and suitable for
> > > synthesis?
> >
> > Don't bother.  You are trying do do something in an FPGA that is not
> > supposed to be done, and is contrary to good digital and FPGA design
> > practices.
> >
> > (snip)
> >
> > --
> > Greg Neff
> > VP Engineering
> > *Microsym* Computers Inc.
> > greg@guesswhichwordgoeshere.com
> >
> > Sent via Deja.com
> > http://www.deja.com/
> >
>
> Sent via Deja.com
> http://www.deja.com/


Article: 28195
Subject: Re: Methodology
From: iglasner@zumanetworks.com
Date: Wed, 27 Dec 2000 22:06:10 GMT
Links: << >>  << T >>  << A >>
Hi,

   Talking about xilinx-tool-support I would even like more that Xilinx
will use the edif from the rev directory thus enabling us running
several edif on the same gui without the need to open few design and
use the command-line.

also than once they get the ncf from synplicity it will not be "read-
only" but rather more like the ucf.

have a nice day

   Illan

In article <921hee$sv0@src-news.pa.dec.com>,
  murray@pa.dec.com (Hal Murray) wrote:
>
>
> > (3) Do builds from the command line. Learning how to use ``make''
will
> > vastly repay the effort.
>
> How many other people would be happier if Xilinx "supported" make
style
> development?
>
> I think the key part that I haven't found is a file flow diagram.
> What files are "source" and need to be preserved by RCS/CVS/whatever?
> What files are machine generated (and easy to recreate) and
> which programs make them?  Which files do those programs read?
>
> Yes, I'm fishing for the data needed to build a makefile.
>
> An app-note would be a wonderful idea.
>
> --
> These are my opinions, not necessarily my employers.  I hate spam.
>


Sent via Deja.com
http://www.deja.com/

Article: 28196
Subject: Re: Methodology
From: eml@riverside-machines.com.NOSPAM
Date: Wed, 27 Dec 2000 22:14:02 GMT
Links: << >>  << T >>  << A >>
On 23 Dec 2000 06:41:18 GMT, murray@pa.dec.com (Hal Murray) wrote:

>> (3) Do builds from the command line. Learning how to use ``make'' will
>> vastly repay the effort.
>
>How many other people would be happier if Xilinx "supported" make style
>development?
>
>
>I think the key part that I haven't found is a file flow diagram.

Loads of them in those online docs... :)

>What files are "source" and need to be preserved by RCS/CVS/whatever?
>What files are machine generated (and easy to recreate) and
>which programs make them?  Which files do those programs read?
>
>Yes, I'm fishing for the data needed to build a makefile.
>
>An app-note would be a wonderful idea.

Here are a couple of extracts from a rev control guidelines doc I
wrote a few years ago:

===================================================================
Which files should be archived?

Adding unnecessary project members, and checking in some types of
files more frequently than necessary, can be particularly wasteful.
The basic guideline is to compromise between the minimum number of
source files required to simulate, synthesise, and rebuild a given
bitstream,  and any additional files which may be required for
convenience. There is, for example, little or no point in saving the
contents of a ModelSim work directory, since it can be quickly
regenerated. On the other hand, a Xilinx ncd file is a large binary
file which is not essential, but it can take many hours to regenerate,
and is useful as an input to EPIC. In this case, the ModelSim work
directory contents should not be archived, and the ncd file should be
archived.

===================================================================
(extract of files to archive: add lots more for the RTL source 
directories, synth directories, test directories, the tools
themselves, etc.)

$CHIP1\xilinx\
  current\         Current implementation
  jtag.ut          Bitgen user option file
  prom.ut          Bitgen user option file
  LOGFILE          Implementation log file
  chip1.ucf        Device User Constraints File
  xilinx.mk        Implementation makefile: entire back-end processing

 $CHIP1\xilinx\current\
  chip1.bld        ngdbuild report file
  map.mrp          Map report file
  ngd2vhdl.log     ngd to vhdl report file
  chip1.pad        Pad specification file
  chip1.par        PAR report file
  chip1.pcf        Physical Constraints file
  chip1.twr        STA report file
  chip1.ncd        Output NCD database
  *.bit            Bitfile output
  *.mcs            MCS PROM output

===================================================================

On a separate note, I wouldn't use CVS unless I was told to. It's
almost (or is?) unique in not having a reserved checkout model, which
can screw up multi-user development, particularly in an environment
where a large number of archived files are machine-generated, as ours
is. A lot of people will disagree with this, but they are, IMHO, plain
wrong.

Evan

Article: 28197
Subject: Re: Newbie question on clock timing generation
From: blueflyer@my-deja.com
Date: Wed, 27 Dec 2000 22:15:30 GMT
Links: << >>  << T >>  << A >>
Thanks, it is really useful.


In article <3A4A6086.36E31AC2@xilinx.com>,
  peter.alfke@xilinx.com wrote:
> You route the common clock to all flip-flops.
> Then you design a state machine that generates clock enable signals
> that you route to the appropriate flip-flops' CE inputs..
> For example, a CE signal that is High for one out of three clock
periods
> enables your CLK/3 flip-flops.
>
> Such state machines ( you might also call them counters )
> can easily be designed with a few CLBs.
> Really very big and fancy ones can be designed with BlockRAM.
>
> Peter Alfke, Xilinx Applications
> =================================================
> blueflyer@my-deja.com wrote:
>
> > Greg,
> >
> > I already realized that gated clock is not good practice in FPGA. My
> > question is how can we clock two subcircuit with different rates if
all
> > the FFs are driven by the same Master clock? Say I have two
subcircuits,
> > one is clocked at Clk_master/3, and the other Clk_master/2.
> >
> > Thanks.
> >
> > In article <92da8r$jfj$1@nnrp1.deja.com>,
> >   Greg Neff <gregneff@my-deja.com> wrote:
> > > In article <929hob$t60$1@nnrp1.deja.com>,
> > >   blueflyer@my-deja.com wrote:
> > > > Merry X'mas!! Unfortunated, I am back to work.
> > > >
> > > > I have a question and will appreciate anybody who can help
clarify
> > it:
> > > >
> > > > - I need to generate a clock for a circuit with many
subcirccuits in
> > > it.
> > > >
> > > > - The circuit is driven by a master clock (Clk).
> > > >
> > >
> > > Right. You drive *all* flip-flops in the FPGA directly from this
> > master
> > > clock, using global clock routing resources.
> > >
> > > > - Each subcircuit has it's own clock derived from the master
clock,
> > > > and each clock has different clock rate (say Clk/2, Clk/4,
Clk/5,
> > > > Clk/7).
> > > >
> > >
> > > Wrong!  Don't do this.  Instead, use the divider outputs as clock
> > > enables for the flip-flops.
> > >
> > > > - Each subcircuit is actived at different time and at different
Clk
> > > > edges (say the first subcircuit is activated at
12*Clk'rising_edge,
> > > done
> > > > at 19*Clk'falling_edge. 20*Clk'falling_edge starts the second
> > > subcircuit
> > > > and deactivated at 37*Clk'rising_edge......)
> > >
> > > You can use the rising and falling edges of the master clock, if
> > > necessary.
> > >
> > > >
> > > > - To keep the power low, the clocks for each subcircuit may be
> > gated.
> > > >
> > >
> > > No, they may not be gated.  Unless you know exactly what you are
> > doing,
> > > and the internal architecture of the FPGA, you *must* clock all
flip-
> > > flops directly from global clock nets.  No gates.
> > >
> > > > Now the question is how to implement this in VHDL and suitable
for
> > > > synthesis?
> > >
> > > Don't bother.  You are trying do do something in an FPGA that is
not
> > > supposed to be done, and is contrary to good digital and FPGA
design
> > > practices.
> > >
> > > (snip)
> > >
> > > --
> > > Greg Neff
> > > VP Engineering
> > > *Microsym* Computers Inc.
> > > greg@guesswhichwordgoeshere.com
> > >
> > > Sent via Deja.com
> > > http://www.deja.com/
> > >
> >
> > Sent via Deja.com
> > http://www.deja.com/
>
>


Sent via Deja.com
http://www.deja.com/

Article: 28198
Subject: Re: Question about programming xcv100
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 28 Dec 2000 00:14:54 -0800
Links: << >>  << T >>  << A >>
On Wed, 27 Dec 2000 06:35:26 +0100, "Domagoj" <domagoj@engineer.com> wrote:
>Hi Philip,
>
>Philip Freidin <philip@fliptronics.com> wrote 
>> On Sun, 24 Dec 2000 00:29:06 GMT, longwayhome@my-deja.com wrote:
>> >In article <3A45264E.F4FBE995@xilinx.com>,
>> Edit a P&R NCD with JBITS. This program was created by people
>> like you, for you. It is a Java interface to the bitstream. You use it
>> either to creat a bitstream from scratch, or to modify an existing
>> bitstream.
>
>    Do you maybe know the price of JBITS package ?

It's FREE

>Any discounts for universities ?

It's FREE for universities too !

>I haven't found much info on Xilinx site about that sw.

Send email to  JBits@xilinx.com and ask for the access.

They will tell you how to get it (via FTP), and docs, and apps.

>Thanks.

You are welcome. Happy new year.

>-------------------------------------------
>-             Domagoj              -
>- Domagoj@engineer.com -
>-------------------------------------------


Philip Freidin
Fliptronics

Article: 28199
Subject: Re: really fast counter in SpartanXL?
From: "markp" <map@nospam_dial.pipex.com>
Date: Thu, 28 Dec 2000 11:59:02 -0000
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
news:3A453A6D.3A4D590A@xilinx.com...
>
>
> markp wrote:
>
> > The fastest counters in my experience are LFSRs (linear feedback shift
> > registers) - the outputs aren't  binary and you only get (2^n)-1 states
(all
> > zeros aren't valid), but these are basically shift registers with an xor
> > feedback term and they use the fast carry logic. Maybe you can get
software
> > to do the reverse conversion if that is not in the critical path. Search
> > Xilinx website for LSFRs.
> > .
>
> I disagree ( and I am the one who wrote the Xilinx app note on LFSRs.  :-)
> LFSRs are the fastest synchronous counters, since they do NOT use the
carry
> chain, but just an XNOR feedback. (XNOR makes all-zero legal, but skips
> all-ones, a better choice.) There is even a fairly simple trick to make an
LFSR
> go through all possible states.
> LFSRs were more popular before Xilinx and Altera incorporated fast
(ripple-)
> carry logic in their FPGAs.
>

Here's a case of being blinded by synchronous design techniques! Oh and I
made a mistake with the fast carry as you have pointed out, sorry. I
recently had to do a design that involved creating a 32bit pseudo random
number on each clock edge (for soak testing memory) and ended up using a
pair of LFSRs as this seemed to be the fastest way to do it. I guess I still
had those thoughts echoing through my head.

> BTW, the LFSR is also the champion high-power consumption counter, with
> statistically 50% of its flip-flops changing state on every clock tick.
> Synchronous binary is much better, and ripple binary is best.

Good point!

>There is even a fairly simple trick to make an LFSR
> go through all possible states.

I seem to recall this involved a bit of decoding and hence slowed it down a
bit, is this still the case?

Mark.






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