Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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
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 FliptronicsArticle: 28178
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, MysticArticle: 28179
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
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
Does somebody know this free software conatin any static timing analyzer. Sent via Deja.com http://www.deja.com/Article: 28182
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 systemArticle: 28183
pinhas@my-deja.com wrote: > Does somebody know this free software conatin any static timing > analyzer. Yes, it's in Designer.Article: 28184
> 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
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
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
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. =
The=20
counter was constructed of a 4-bit Johnson Ring counter appended to a =
12-bit=20
conventional counter. It used SRLs, but you can to the same thing =
with=20
flops. 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> </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. You can't get any =
faster=20
than that for synchronous circuits. Here's what you do. The =
LSB is a=20
Johson ring (shift register with one end tied to the other in a ring) =
with two=20
flops. One has a reset value of 1, the other zero. They just =
trade=20
the 1 and 0. Bit 1 is made of a ring of 4 flops, with the reset values=20
'0011'. You can see that the first flop in the ring will change =
every 2nd=20
cycle. Bit 2 is made of 8 flops, with reset values '00001111' and =
bit 3 of=20
16 flops with reset values '0000000011111111'. Using the first =
flop in=20
each of the four rings, you have a 4-bit counter. There is an =
XCell=20
article that relates to this.</FONT></DIV>
<DIV> </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> </DIV>
<DIV><FONT size=3D2>Now you can append a conventional 12-bit counter =
(with carry=20
chain) to this counter. 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'. Actually it would be faster to pipeline this: you =
would have=20
a flop that would 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. That would =
require=20
one level of logic. This is probably your critical =
path.</FONT></DIV>
<DIV> </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. =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> </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. The carry =
chain=20
has 16 cycles to propagate. You just need to make sure to inform =
the=20
synthesizer of that fact. You may be able to use instead a 3-bit=20
Johson-ring counter and a 13-bit conventional counter.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>It seems like this should actually match the speed =
of a=20
ripple, but in any case you should make your 208MHz goal and you =
will avoid=20
routing clocks and will have a synchronous design. 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> </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 <<A=20
=
href=3D"mailto:3A3814B5.660E2B3F@xilinx.com">3A3814B5.660E2B3F@xilinx.com=
</A>>...</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 =
(<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? I need a 16 bit =
counter with=20
enable and reset.clock <BR>on negative edge preferred but not=20
critical. 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. The _only_ <BR>factor of =
importance is=20
_speed_. 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? I =
need to=20
get up to 204.8MHz toggle frequency. 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
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: 28189In 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
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
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: 28192The 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
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
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
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
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. EvanArticle: 28197
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
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 FliptronicsArticle: 28199
"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:
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