Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 135450

Article: 135450
Subject: Re: $99 XMOS Dev kit
From: "Anthony Fremont" <nobody@noplace.net>
Date: Thu, 2 Oct 2008 09:07:54 -0500
Links: << >>  << T >>  << A >>
Leon wrote:
> On 1 Oct, 18:38, Leon <leon...@btinternet.com> wrote:

>> They are having lots of problems with their web site. I was able to
>> register OK with Firefox, but didn't get my password, although the
>> message said it was being sent. I used their Support facility, and
>> they emailed the password manually to me.
>>
>> They now have schematics and design files for the XC-1 board
>> available:
>>
>> https://support.xmos.com/published/xc1-schematics
>>
>> Leon
>>
>> Leon
>
> I just had an email from my contact at XMOS and mentioned your
> problem.

Looks like it's working better now.  I was able to look at the tutorials 
online.  Pretty interesting, I may get a dev board and play around with it 
this winter.  Thanks for pointing these out.  :-) 



Article: 135451
Subject: Re: floating point round off errors
From: "jack.harvard@googlemail.com" <jack.harvard@googlemail.com>
Date: Thu, 2 Oct 2008 07:09:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 2, 2:08=A0pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Thu, 2 Oct 2008 00:51:21 -0700 (PDT), "jack.harv...@googlemail.com"
>
> <jack.harv...@googlemail.com> wrote:
> >Hi,
>
> >I implemented some single precision floating point units in FPGA (IEEE
> >754 fully compliant) to calculate some complex mathematical equations,
> >meanwhile, to debug the design modules, I've also got the C source
> >code implementing the equations, with all the variables defined in
> >single precision floating point. The Verilog code should have the same
> >precision as I would expect from the C code. However, I found there
> >are differences between the results generated from FPGA and C, the
> >precision is about 10**(-5), I suppose this could be caused by round
> >off errors. In Verilog, the round off is implemented as "round to the
> >nearest (if equal, round to even)", just wondering when it is done in
> >C, how the round off works, and how AMD/Intel processor does the round
> >off for single precision floating point?
>
> The Intel processor implements all the rounding modes specified in P754.
> How you actually select them is another matter.
>
> If you haven't already found Prof. Kahan's papers on P754, do so...
>
> Unfortunately C is a TERRIBLE language for this purpose (working in
> single precision floating point); the Visual C compilers especially so;
> they take liberties with precision, tending to assume you really want
> double precision and silently implementing it for you...
>
> ... then by forcing data into volatile "float" variables, you finally
> get your code to round as expected. Then you decide to abstract over it
> with a function, and....
>
> C specifies that float arguments passed to functions are automagically
> coerced into doubles, so your code automagically breaks again...
>
> Personally I wouldn't worry about the Verilog unless you are ABSOLUTELY
> CERTAIN the C code is doing EXACTLY what you expect...
>
> it may turn out that the Verilog implementation is accumulating single
> precision float rounding errors exactly as it should, while the C code
> is assuming you didn't want what you asked for and giving you double
> precision instead.
>
> - Brian
> (no I don't much like C; why do you ask? :-)

Thanks for all your replies, a little more information which I got
today. Both are in single precision floating point, the results are
0x40984d30(Verilog) and 0x40984d36(C), and the two values translate to
4.759422302246094 (Verilog) and 4.759425163269043 (C). And, a better
result given by mathematical tool is 4.75942303685175 (regard this as
the expected result), the precision is 10**(-6) for both verilog for
C, but Verilog has a smaller error, which is quite intriguing, as I
would expect the precision not to be worse in C than in Verilog, as
the internal computations are done in double-precision floating point
in C as pointed out above.

Article: 135452
Subject: Re: $99 XMOS Dev kit
From: Leon <leon355@btinternet.com>
Date: Thu, 2 Oct 2008 07:15:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 2 Oct, 15:07, "Anthony Fremont" <nob...@noplace.net> wrote:
> Leon wrote:
> > On 1 Oct, 18:38, Leon <leon...@btinternet.com> wrote:
> >> They are having lots of problems with their web site. I was able to
> >> register OK with Firefox, but didn't get my password, although the
> >> message said it was being sent. I used their Support facility, and
> >> they emailed the password manually to me.
>
> >> They now have schematics and design files for the XC-1 board
> >> available:
>
> >>https://support.xmos.com/published/xc1-schematics
>
> >> Leon
>
> >> Leon
>
> > I just had an email from my contact at XMOS and mentioned your
> > problem.
>
> Looks like it's working better now. =A0I was able to look at the tutorial=
s
> online. =A0Pretty interesting, I may get a dev board and play around with=
 it
> this winter. =A0Thanks for pointing these out. =A0:-)

I've just seen on the Xlinkers forum that they will start shipping the
XC-1 kits next week. The forum isn't very active yet, but it's worth
joining:

http://www.xlinkers.org/

Leon

Article: 135453
Subject: Re: Gee Thanks Altera, I really enjoy having a break waiting on your
From: Leon <leon355@btinternet.com>
Date: Thu, 2 Oct 2008 07:45:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 1 Oct, 23:28, LittleAlex <alex.lo...@email.com> wrote:
> On Oct 1, 10:44 am, cs_post...@hotmail.com wrote:
>
> > Project behind schedule... but Quartus decides that today is the day
> > to demand a new license file.
>
> > Which the server has promised but not yet mailed.
>
> > Don't you just love control-freak software?
>
> Note to self: =A0Next time don't ignore the "your license will expire in
> xx days" messages.

They are pretty quick getting the licenses out, as a rule. I usually
get mine in a couple of minutes.

Leon

Article: 135454
Subject: Two questions about Xilinx constraints setting
From: "commone" <dechenxu@yahoo.com.cn>
Date: Thu, 02 Oct 2008 10:42:46 -0500
Links: << >>  << T >>  << A >>
Hi all,
   I have two questins about xilinx constraints setting. 

First, for the input constraints, how to create a constraint for "hold
time". As I know, OFFSET IN BEFORE and OFFSET IN AFTER are both for the
"setup time" contraints. And if there is no constraint for hold time, then
how the "hold slack" is computed.

Second, how the relationship of the "clock enable" signal and the clock
signal is constrainted.  

Article: 135455
Subject: Re: reasonable timing analysis without mapping design to IO
From: Heiner Litz <heinerlitz@googlemail.com>
Date: Thu, 2 Oct 2008 09:17:41 -0700 (PDT)
Links: << >>  << T >>  << A >>

> You can disable the automated insertion of IO symbols with XST. To preven=
t
> the mapped from throwing away all logic from your design, disable the "tr=
im
> unconnected signals" in ISE.

Hmm doesn't work for me:

ERROR:Pack:198 - NCD was not produced.  All logic was removed from the
design.
   This is usually due to having no input or output PAD connections in
the
   design and no nets or symbols marked as 'SAVE'.  You can either add
PADs or
   'SAVE' attributes to the design, or run 'map -u' to disable logic
trimming in
   the mapper.  For more information on trimming issues search the
Xilinx
   Answers database for "ERROR:Pack:198" and read the Master Answer
Record for
   MAP Trimming Issues.

I disabled trim signals and the automatic insertion of IO symbols.

>
> > On Oct 1, 1:25 am, Andy <jonesa...@comcast.net> wrote:
> >> On Sep 30, 2:27 pm, Kevin Neilson
>
> >> <kevin_neil...@removethiscomcast.net> wrote:
> >>> Heiner Litz wrote:
> >>>> Hi,
> >>>> I want to perform reasonable post place&route timing analysis for so=
me
> >>>> RTL modules. The modules have a higher pin count as the FPGA itself.
> >>>> ISE always tries to map the modules I/Os to specific IO pads, so its
> >>>> not possible to make post P&R timing analysis for such (internally
> >>>> used) modules.
> >>>> The post synthesis timing is unrealistic, so how can I get a timing
> >>>> estimation including wire delay for dedicated modules?
> >>>> Any ideas?
> >>> If the problem is that you don't have enough pins on the device, you
> >>> could make sure all the I/O are registered, instruct the synthesizer =
not
> >>> to add IOB pads, and put syn_keep or syn_preserve (or whatever) HDL
> >>> directives on the I/O registers to make sure they don't get pruned.
> >>> Then you could have a static timing analysis even though no pins are
> >>> connected. =A0You won't be able to easily use this for a simulation, =
since
> >>> none of the I/Os will come out to top-level ports. =A0-Kevin
> >> No, just turn all those external registers into a parallel/serial
> >> shift register, and only output the serial output.
>
> >> Reverse for the input: serial/parallel shift register, and the only
> >> chip-level input is the serial input.
>
> >> A clock, input and output pin; should fit in anything.
>
> >> Andy


Article: 135456
Subject: Re: reasonable timing analysis without mapping design to IO
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 02 Oct 2008 09:39:03 -0700
Links: << >>  << T >>  << A >>
Heiner Litz wrote:

> I want to perform reasonable post place&route timing analysis for some
> RTL modules. The modules have a higher pin count as the FPGA itself.


Since the complete design fits the pins,
why not run STA on that?

      -- Mike Treseler

Article: 135457
Subject: Re: Two questions about Xilinx constraints setting
From: "commone" <dechenxu@yahoo.com.cn>
Date: Thu, 02 Oct 2008 12:25:06 -0500
Links: << >>  << T >>  << A >>
>Hi all,
>   I have two questins about xilinx constraints setting. 
>
>First, for the input constraints, how to create a constraint for "hold
>time". As I know, OFFSET IN BEFORE and OFFSET IN AFTER are both for the
>"setup time" contraints. And if there is no constraint for hold time,
then
>how the "hold slack" is computed.
>
>Second, how the relationship of the "clock enable" signal and the clock
>signal is constrainted.  
>

I have find the answer for the first question. It's the keyword VALID that
is used to define the data valid window.

But, anyone got the answer for the second question?


Article: 135458
Subject: WEBPACK for linux
From: "beky4kr@gmail.com" <beky4kr@gmail.com>
Date: Thu, 2 Oct 2008 11:35:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
A few years ago I downloaded the WEBPACK for linux.
I checked recently in http://www.xilinx.com/support/download/index.htm
and it seems the free version is only for windows.

Does xilinx stop to give it for free (the linux version).

Article: 135459
Subject: Re: floating point round off errors
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 02 Oct 2008 10:43:38 -0800
Links: << >>  << T >>  << A >>
jack.harvard@googlemail.com wrote:
> On Oct 2, 2:08 pm, Brian Drummond <brian_drumm...@btconnect.com>
> wrote:
(snip on floating point in verilog and C)

>>Unfortunately C is a TERRIBLE language for this purpose (working in
>>single precision floating point); the Visual C compilers especially so;
>>they take liberties with precision, tending to assume you really want
>>double precision and silently implementing it for you...

Code for the intel x87 floating point processor normally
generates extended precision (64 bit significand) results.
There are bits to reduce the precision for some, but not all,
operations, but it isn't normally changed.

>>... then by forcing data into volatile "float" variables, you finally
>>get your code to round as expected. Then you decide to abstract over it
>>with a function, and....

>>C specifies that float arguments passed to functions are automagically
>>coerced into doubles, so your code automagically breaks again...

For ANSI C, and with a prototype in scope, float should be
passed as float.  For varargs they are passed as double.

>>Personally I wouldn't worry about the Verilog unless you are ABSOLUTELY
>>CERTAIN the C code is doing EXACTLY what you expect...

>>it may turn out that the Verilog implementation is accumulating single
>>precision float rounding errors exactly as it should, while the C code
>>is assuming you didn't want what you asked for and giving you double
>>precision instead.

> Thanks for all your replies, a little more information which I got
> today. Both are in single precision floating point, the results are
> 0x40984d30(Verilog) and 0x40984d36(C), and the two values translate to
> 4.759422302246094 (Verilog) and 4.759425163269043 (C). And, a better
> result given by mathematical tool is 4.75942303685175 (regard this as
> the expected result), the precision is 10**(-6) for both verilog for
> C, but Verilog has a smaller error, which is quite intriguing, as I
> would expect the precision not to be worse in C than in Verilog, as
> the internal computations are done in double-precision floating point
> in C as pointed out above.

Among other causes for wrong results is double rounding.

With x87, you can round from 64 bits to 53 and then to 24,
giving a different result from the proper rounding
from 64 to 24 bits.

Also, doing some parts of a calculation with extra precision,
but not all, can result in different results.

-- glen


Article: 135460
Subject: Re: Two questions about Xilinx constraints setting
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 02 Oct 2008 11:55:27 -0700
Links: << >>  << T >>  << A >>
commone wrote:

>> Second, how the relationship of the "clock enable" signal and the clock
>> signal is constrainted.  

> I have find the answer for the first question. It's the keyword VALID that
> is used to define the data valid window.
> But, anyone got the answer for the second question?


clock is a clock
clock enable is an input

        -- Mike Treseler

Article: 135461
Subject: Re: Two questions about Xilinx constraints setting
From: "commone" <dechenxu@yahoo.com.cn>
Date: Thu, 02 Oct 2008 14:02:55 -0500
Links: << >>  << T >>  << A >>
>Hi all,
>   I have two questins about xilinx constraints setting. 
>
>First, for the input constraints, how to create a constraint for "hold
>time". As I know, OFFSET IN BEFORE and OFFSET IN AFTER are both for the
>"setup time" contraints. And if there is no constraint for hold time,
then
>how the "hold slack" is computed.
>
>Second, how the relationship of the "clock enable" signal and the clock
>signal is constrainted.  
>

Does ISE treat the "CE" input of a Flip-flop the same as the "D" input
during Place&route and Static timing analysis?

Article: 135462
Subject: Re: Two questions about Xilinx constraints setting
From: "commone" <dechenxu@yahoo.com.cn>
Date: Thu, 02 Oct 2008 14:06:08 -0500
Links: << >>  << T >>  << A >>
>commone wrote:
>
>>> Second, how the relationship of the "clock enable" signal and the
clock
>>> signal is constrainted.  
>
>> I have find the answer for the first question. It's the keyword VALID
that
>> is used to define the data valid window.
>> But, anyone got the answer for the second question?
>
>
>clock is a clock
>clock enable is an input
>
>        -- Mike Treseler
>
Thank u Mike! :)


Article: 135463
Subject: Re: WEBPACK for linux
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 02 Oct 2008 15:13:02 -0500
Links: << >>  << T >>  << A >>
beky4kr@gmail.com wrote:
> A few years ago I downloaded the WEBPACK for linux.
> I checked recently in http://www.xilinx.com/support/download/index.htm
> and it seems the free version is only for windows.
> 
> Does xilinx stop to give it for free (the linux version).
They still have the free Linux version, for 32-bit architecture ONLY!
If you have a 64-bit system, there apparently is a way to make it work, 
too.  I didn't want to do that much hacking, and we have a site license 
for the "real thing".

Jon

Article: 135464
Subject: Re: floating point round off errors
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 03 Oct 2008 00:48:08 +0100
Links: << >>  << T >>  << A >>
On Thu, 02 Oct 2008 10:43:38 -0800, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>>>... then by forcing data into volatile "float" variables, you finally
>>>get your code to round as expected. Then you decide to abstract over it
>>>with a function, and....
>
>>>C specifies that float arguments passed to functions are automagically
>>>coerced into doubles, so your code automagically breaks again...
>
>For ANSI C, and with a prototype in scope, float should be
>passed as float.  For varargs they are passed as double.

*cough* serves me right for consulting my copy of K&R again.
I hear there's a second edition out...

you're right of course. But it's a bit alarming that it'll compile
without a visible prototype, and silently deliver different results.

>> Thanks for all your replies, a little more information which I got
>> today. Both are in single precision floating point, the results are
>> 0x40984d30(Verilog) and 0x40984d36(C), and the two values translate to
>> 4.759422302246094 (Verilog) and 4.759425163269043 (C). And, a better
>> result given by mathematical tool is 4.75942303685175 

I make Verilog 1.5E-7 (error/correct) and C 4.5E-7, or 3x the error.

Which suggests the correct result is 1.5 LSBs greater than the Verilog
result. Or alternatively, the best you can achieve is 1/3 of the current
error.

>Among other causes for wrong results is double rounding.
>
>With x87, you can round from 64 bits to 53 and then to 24,
>giving a different result from the proper rounding
>from 64 to 24 bits.
>
>Also, doing some parts of a calculation with extra precision,
>but not all, can result in different results.

Yes.

At this point there are two aspects to consider:
(1) the correctness of the Verilog implementation. This would be easy to
check if you had a numerically reliable (not accurate! but correct in
single precision) reference implementation to compare against.

(2) the importance of errors in the application anyway. (It may be worth
using higher precision internally in critical areas).

If small errors are tolerable, you might get away with the current
Verilog implementation; compare its output against a high accuracy model
with acceptable tolerance bounds 
(e.g. assert an error if abs(worst case error) >=  0.5e-6).

If the Verilog implementation must be correct, you will need a reference
implementation in which every operation is known to be correct to single
precision (the difficult bit, in C!), and test for bitwise identical
results.

- Brian


Article: 135465
Subject: Re: Standalone Altera production programmer
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 03 Oct 2008 13:14:15 +1200
Links: << >>  << T >>  << A >>
news@rblack01.plus.com wrote:

> Hi,
> 
> Does anybody make a standalone (i.e. non PC-based) programmer for
> Altera devices?
> Our product uses a Cyclone which loads its config from a EPCS1 1-Mbit
> EEPROM at power-up.  To program the EEPROM in production we are using
> a PC running Quartus, and a ByteBlaster.  This works OK, but is a bit
> cumbersome and prone to error (e.g. operator selects wrong object
> file)
> 
> To program the Microchip PICs in the same product we use a fag-packet
> sized programmer from www.kanda.com - these are battery powered, data
> downloaded via a cable from a PC, the only user interface is one
> button and a green/red LED, completely idiot-proof.
> 
> I've been trying to find an equivalent product for Altera devices,
> without success.  I'm now considering making one for my own use, based
> on an MCU + external Flash chip.  If I did, would it be worth selling?

Commercial programmers will pgm the EPCS1.
(one example is eetools ChipMax-2)

These typically have a Project file, so you can save the source+device,
and reduce operator errors, and a front panel button, so users do
not even have to touch the PC...

-jg



Article: 135466
Subject: Re: floating point round off errors
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 02 Oct 2008 19:14:28 -0800
Links: << >>  << T >>  << A >>
Brian Drummond wrote:
(snip, I wrote)

>>For ANSI C, and with a prototype in scope, float should be
>>passed as float.  For varargs they are passed as double.

> *cough* serves me right for consulting my copy of K&R again.
> I hear there's a second edition out...

I wonder when the third edition will be out.

> you're right of course. But it's a bit alarming that it'll compile
> without a visible prototype, and silently deliver different results.

Just as Fortran will do without an interface, and for the
same reason: backward compatibility.

(snip)

> At this point there are two aspects to consider:
> (1) the correctness of the Verilog implementation. This would be easy to
> check if you had a numerically reliable (not accurate! but correct in
> single precision) reference implementation to compare against.

> (2) the importance of errors in the application anyway. (It may be worth
> using higher precision internally in critical areas).

The nice thing about verilog implementations is that you
can easily add bits, even one or two.  That is hard on a
processor with fixed sized registers.

> If small errors are tolerable, you might get away with the current
> Verilog implementation; compare its output against a high accuracy model
> with acceptable tolerance bounds 
> (e.g. assert an error if abs(worst case error) >=  0.5e-6).

> If the Verilog implementation must be correct, you will need a reference
> implementation in which every operation is known to be correct to single
> precision (the difficult bit, in C!), and test for bitwise identical
> results.

There might be some compilers that will force single precision
between every operation.

-- glen


Article: 135467
Subject: Re: Is it possible to get an RTL netlist from Xilinx tools?
From: thutt <thutt151@comcast.net>
Date: 02 Oct 2008 20:20:48 -0700
Links: << >>  << T >>  << A >>
Eric Smith <eric@brouhaha.com> writes:

> Kevin Neilson wrote:
> > Sure, you can determine that a LUT with a INIT code of FFFE is an
> > inverter.
> 
> thutt wrote:
> > Can you point me to a reference that shows how to do this?
> 
> Any textbook on digital logic!
> 
> You have a logic circuit with four inputs, with the truth table:
> 
>     ABCD   Q        ABCD   Q    
>     ----   -        ----   -    
>     0000   1        1000   1    
>     0001   1        1001   1    
>     0010   1        1010   1    
>     0011   1        1011   1    
>     0100   1        1100   1    
>     0101   1        1101   1    
>     0110   1        1110   1    
>     0111   1        1111   0    
> 
> It should be immediately obvious that the circuit is a four-input NAND, and
> that if any three inputs are tied high, Q is the inverse of the fourth input.

I didn't actually mean the math part, I meant converting the
initialization string into something usable.  I have, since my query,
talked to an actual hardware-type person and he's explained how this
stuff works down at the metal, and now I comprehend how to convert the
technology netlist into an RTL netlist.

Now, it's just a matter of time & will to do it.

thutt

-- 
Hoegaarden!

Article: 135468
Subject: Re: WEBPACK for linux
From: thutt <thutt151@comcast.net>
Date: 02 Oct 2008 20:25:13 -0700
Links: << >>  << T >>  << A >>
Jon Elson <jmelson@wustl.edu> writes:

> beky4kr@gmail.com wrote:
> > A few years ago I downloaded the WEBPACK for linux.
> > I checked recently in http://www.xilinx.com/support/download/index.htm
> > and it seems the free version is only for windows.
> > Does xilinx stop to give it for free (the linux version).
> They still have the free Linux version, for 32-bit architecture ONLY!
> If you have a 64-bit system, there apparently is a way to make it
> work, too.  I didn't want to do that much hacking, and we have a site
> license for the "real thing".
> 
> Jon


One could always use vmware on Linux to create a 32-bit VM in which
you can run the Xilinx tools.  It works very nicely -- redirect X to
your host computer's ${DISPLAY} setting, and ISE will even appear on
your regular monitor (not inside the VM window).

thutt
-- 
Hoegaarden!

Article: 135469
Subject: Re: Low frequency clock generation - need help
From: thutt <thutt151@comcast.net>
Date: 02 Oct 2008 21:09:12 -0700
Links: << >>  << T >>  << A >>
Svenn Are Bjerkem <svenn.bjerkem@googlemail.com> writes:

> On Sep 30, 6:01 am, thutt <thutt...@comcast.net> wrote:
> > vlod...@gmail.com writes:
> > > Guys,
> >

<snip>

> > I'm certainly no expert in the field of hardware design, but I've had
> > good luck using the master clock signal and an 'enable' that runs at
> > the desired clock speed.  I've successfully used this technique to
> > divide the Spartan 3E 50MHz clock down to 230Khz for serial port
> > transmission.
> >
> > I'd be happy to provide the entity which produces the 'enable' signal
> > and an example of how to use it if you're interested.
> 
> please provide,

Svenn,

Since you asked, and since it appears to be something that's not so
easily findable on the net -- at least with my google-fu -- I'm going
to post the sample and the library here rather than in private email.
I hope it doesn't violate any general rules of this newsgroup.  I also
hope that if I've done something insanely stupid in the code that
someone more knowledgeable will point that out.

1. the clock divider.

  I started out with a clock divider I found by Brian Boorman.  The
  version I downloaded didn't compile, and I had to make
  modifications.  After getting it to work, I decided that *I* felt
  the code was ugly and could use a little sprucing up to make it more
  accessible.

  I then used that version for a while until I ran into some clock
  issues and I was admonished by my hardware guardian angel that it
  would be best to have only a single clock in your design and to use
  an 'enable'.

  Of course, it's not straightforward how to get an 'enable pulse' to
  occur when desired, but only for one cycle of the master clock
  signal.

  For example, consider a 50MHz master clock (like the Spartan 3E) and
  a divided clock of 230,400 Hz.  Originally, the clock divider entity
  output a wave form that was 230,400Hz - but that would be many, many
  clocks at 50MHz.  I only wanted ONE pulse at 50 MHz for each
  transition of the 230,400 Hz clock.  This is accomplished with a
  two flip flops (i.e., the normal trick used to cross clock domains)
  and a little extra logic.  This is implemented using 'shift_reg' and
  the assignment to 'clk_enable'.

  The 'clock_divisor' generic input is the divisor used to produce the
  desired clock.  Taking the 50MHz / 230400 Hz example, the divisor is
  14.  The 230,400 Hz value is a serial port speed.  So, the value is
  calculated like this:

      master clock / desired-bps / special-divisor

      50,000,000 / 230,400 / 15

  The special divisor was tediously calculated by hand.  I won't go
  into the details here, but I may someday on
  http://www.harp-project.com/.

  Below I have an example which will blink the LEDs on the Spartan 3E
  board at 1, 10 and 100 Hz, so you'll see another example.

   --- begin clock divider ---
   -- Copyright (c) 1997 Brian Boorman, Harris RF Communications, Rochester, NY
   --
   -- Originally code found here:
   --   http://www.edn.com/archives/1997/081597/17di_01.htm
   --
   -- This version of the code is fixed from the original, and then
   -- cleaned up in terms of formatting and simplicity, but the original
   -- code still is largely intact.

   library ieee;
   use ieee.std_logic_1164.all;

   entity clkdiv_enable is
     generic(clock_divisor: natural := 3);
     port(clkin      : in  std_logic; -- 50% Duty Cycle Input Clock
          reset      : in  std_logic; -- Active high reset
          clk_enable : out boolean);
   end clkdiv_enable;

   architecture lms of clkdiv_enable is
     -- This subtype will constrain counter width.
     subtype divtype_t is natural range 0 to clock_divisor - 1;

     constant is_valid    : boolean := clock_divisor >= 1;
     constant is_passthru : boolean := clock_divisor = 1;
     constant is_half     : boolean := clock_divisor = 2;
     constant is_odd      : boolean := (((((clock_divisor / 2) * 2)) =
                                         (clock_divisor - 1)) and
                                        (clock_divisor > 2));
     constant is_even     : boolean := (((((clock_divisor / 2) * 2)) =
                                         clock_divisor) and
                                        (clock_divisor > 2));

     signal enable    : std_logic;
     signal shift_reg : std_logic_vector(1 downto 0);
     signal counter   : divtype_t;
     signal en_tff    : std_logic_vector(boolean'pos(is_odd) downto 0);
     signal divisor   : std_logic_vector(boolean'pos(is_odd) downto 0);

     function std_logic_to_bool(s : std_logic) return boolean is
     begin if s = '1' then return true; else return false; end if;
     end function std_logic_to_bool;

   begin
     assert(is_valid)
       report "Clock divisor must be a positive number >= 1"
       severity failure;

     assert(not is_odd)
       report "Clock divisor is odd; will result in a combinatorial clock signal"
       severity failure;

     assert(not is_half)
       report "Generating a half-cycle clock"
       severity warning;

     assert(not is_passthru)
       report "Generating a passthrough clock"
       severity warning;

     assert(not is_even)
       report "Generating an even clock"
       severity warning;

     gOne:
       if is_passthru generate
         enable <= clkin when reset = '0' else
                                '0';
       end generate;

     gTwo:                         -- generate a T Flip-Flop
       if is_half generate
         pTwo: process(clkin, reset, divisor(0))
         begin
           if reset = '1' then
             divisor(0) <= '0';
           elsif rising_edge(clkin) then
             divisor(0) <= not(divisor(0));
           end if;
         end process;
         enable <= divisor(0);
       end generate;

     gOdd:
       if is_odd generate
         pOdd: process(clkin, reset, counter)
         begin
           if reset = '1' then
             counter <= 0;
           elsif rising_edge(clkin) then
             if counter = clock_divisor - 1 then
               counter <= 0;
             else
               counter <= counter + 1;
             end if;
           end if;
         end process;

         en_tff(0) <= '1' when counter = 0 else '0';
         en_tff(1) <= '1' when counter = (((clock_divisor - 1) / 2) + 1) else '0';

         pOddDiv1: process(clkin, reset, en_tff(0), divisor(0))
         begin
           if reset = '1' then
             divisor(0) <= '1';
           elsif rising_edge(clkin) then
             if en_tff(0) = '1' then
               divisor(0) <= not(divisor(0));
             end if;
           end if;
         end process;

         pOddDiv2: process(clkin, reset, en_tff(1), divisor(1))
         begin
           if reset = '1' then
             divisor(1) <= '1';
           elsif falling_edge(clkin) then
             if en_tff(1) = '1' then
               divisor(1) <= not(divisor(1));
             end if;
           end if;
         end process;

         enable <= divisor(0) xor divisor(1);
       end generate;

     gEven:
       if is_even generate
         pEvenDiv: process(clkin, reset, counter)
         begin
           if reset = '1' then
             counter <= 0;
           elsif rising_edge(clkin) then
             if counter = clock_divisor - 1 then
               counter <= 0;
             else
               counter <= counter + 1;
             end if;
           end if;
         end process;

         en_tff(0) <= '1' when ((counter = 0) or
                                 (counter = ((clock_divisor / 2) - 1)) )
                          else '0';

         pEvenDiv1: process(clkin, reset, en_tff(0), divisor(0))
         begin
           if reset = '1' then
             divisor(0) <= '0';
           elsif rising_edge(clkin) then
             if en_tff(0) = '1' then
               divisor(0) <= not(divisor(0));
             end if;
           end if;
         end process;
         enable <= divisor(0);
       end generate;

     shift_reg  <= enable & shift_reg(1) when rising_edge(clkin);
     clk_enable <= std_logic_to_bool(shift_reg(1) and not shift_reg(0));
   end lms;
   --- end clock divider ---

2. Constraints file

  Below is the constraint file which assigns the LEDs to my divided
  clocks.  If you're not using Xilinx software, you'll have to come up
  with your own constraints.

    -- begin UCF file ---

    # This file is part of the Harp Project.
    # Copyright (c) 2007, 2008 Taylor Hutt, Logic Magicians Software
    # http://www.harp-project.com/
    #
    # This program is free software: you can redistribute it and/or
    # modify it under the terms of the GNU General Public License as
    # published by the Free Software Foundation, either version 3 of the
    # License, or (at your option) any later version.
    #
    # This program is distributed in the hope that it will be useful, but
    # WITHOUT ANY WARRANTY; without even the implied warranty of
    # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
    # General Public License for more details.
    #
    # You should have received a copy of the GNU General Public License
    # along with this program.  If not, see <http://www.gnu.org/licenses/>.
    #
    NET "CLK_50MHZ" LOC = "C9"  | IOSTANDARD = LVCMOS33 ;
    NET "CLK_50MHZ" PERIOD = 20.0ns HIGH 40%;
    NET "CLK_1HZ"    LOC = "F12" | IOSTANDARD = LVTTL  | SLEW = SLOW  | DRIVE = 8 ;
    NET "CLK_10HZ"   LOC = "E12" | IOSTANDARD = LVTTL  | SLEW = SLOW  | DRIVE = 8 ;
    NET "CLK_100HZ"  LOC = "E11" | IOSTANDARD = LVTTL  | SLEW = SLOW  | DRIVE = 8 ;

    --- end UCF file ---

3. Sample Design -- Blink LEDs

  Finally, a simple example that I just cooked up that will blink some
  LEDs on the Xilinx board at 1, 10 and 100Hz.

    --- begin Sample VHDL ---

    -- This file is part of the Harp Project.
    -- Copyright (c) 2007, 2008 Taylor Hutt, Logic Magicians Software
    -- http://www.harp-project.com/
    --
    -- This program is free software: you can redistribute it and/or
    -- modify it under the terms of the GNU General Public License as
    -- published by the Free Software Foundation, either version 3 of the
    -- License, or (at your option) any later version.
    --
    -- This program is distributed in the hope that it will be useful, but
    -- WITHOUT ANY WARRANTY; without even the implied warranty of
    -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
    -- General Public License for more details.
    --
    -- You should have received a copy of the GNU General Public License
    -- along with this program.  If not, see <http://www.gnu.org/licenses/>.
    --
    library IEEE;

    use IEEE.STD_LOGIC_1164.ALL;
    use IEEE.STD_LOGIC_ARITH.ALL;
    use IEEE.STD_LOGIC_UNSIGNED.ALL;

    entity main is
        Port (CLK_50MHZ : in  STD_LOGIC;
              CLK_100HZ : out STD_LOGIC;
              CLK_10HZ  : out STD_LOGIC;
              CLK_1HZ   : out STD_LOGIC);
    end main;

    architecture Behavioral of main is

      signal output_1Hz   : std_logic := '0';
      signal output_10Hz  : std_logic := '0';
      signal output_100Hz : std_logic := '0';
      signal enable_1Hz   : boolean;
      signal enable_10Hz  : boolean;
      signal enable_100Hz : boolean;

    begin
      blink_1Hz : process(CLK_50MHZ, enable_1Hz)
      begin
        if enable_1Hz then
          if rising_edge(CLK_50MHZ) then
            output_1Hz <= not output_1Hz;
          end if;
        end if;
      end process blink_1Hz;

      blink_10Hz : process(CLK_50MHZ, enable_10Hz)
      begin
        if enable_10Hz then
          if rising_edge(CLK_50MHZ) then
            output_10Hz <= not output_10Hz;
          end if;
        end if;
      end process blink_10Hz;

      blink_100Hz : process(CLK_50MHZ, enable_100Hz)
      begin
        if enable_100Hz then
          if rising_edge(CLK_50MHZ) then
            output_100Hz <= not output_100Hz;
          end if;
        end if;
      end process blink_100Hz;

      one_hz: entity clkdiv_enable          -- 1 Hz
        generic map (clock_divisor => 50000000)
        port map (clkin => CLK_50MHZ, reset => '0', clk_enable => enable_1HZ);

      ten_hz: entity clkdiv_enable          -- 10 Hz
        generic map (clock_divisor => 5000000)
        port map (clkin => CLK_50MHZ, reset => '0', clk_enable => enable_10HZ);

      one_hundred_hz: entity clkdiv_enable  -- 100 Hz
        generic map (clock_divisor => 500000)
        port map (clkin => CLK_50MHZ, reset => '0', clk_enable => enable_100HZ);

      CLK_100HZ <= output_100Hz;
      CLK_10HZ  <= output_10Hz;
      CLK_1HZ   <= output_1Hz;

    end behavioral;

    --- end  Sample VHDL ---

Keep in mind that I'm not a hardware guy!  I'm a low-level software
guy who's learning hardware.  So, there could very well be things that
I've done that no sane hardware engineer would actually do.  Please be
gentle in critiquing this work.  I do however, think that my version
of the clock divider is definitely easier to read.

thutt
---
Hoegaarden!

Article: 135470
Subject: Re: WEBPACK for linux
From: Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk>
Date: Fri, 03 Oct 2008 08:03:10 GMT
Links: << >>  << T >>  << A >>
Jon Elson <jmelson@wustl.edu> wrote:

>beky4kr@gmail.com wrote:
>> A few years ago I downloaded the WEBPACK for linux.
>> I checked recently in http://www.xilinx.com/support/download/index.htm
>> and it seems the free version is only for windows.
>> 
>> Does xilinx stop to give it for free (the linux version).
>They still have the free Linux version, for 32-bit architecture ONLY!
>If you have a 64-bit system, there apparently is a way to make it work, 
>too.  I didn't want to do that much hacking, and we have a site license 
>for the "real thing".

I've not tried this because I'm still on 32-bits, but I understand that
you need to install the 64-bit distro's 32-bit compatibility libraries.

As to how easy the free Webpack for Linux is to get working in general,
you might need to do a *little* hacking to get it to work, if my
experience of installing it on Mandriva 2006 a couple of years back is
anything to go by...

...as shown in section 5 here:
http://no.gentoo-wiki.com/Talk:HOWTO_Xilinx/Archive_1

...which lists the deviations from the main HOWTO (for Gentoo) here:
http://no.gentoo-wiki.com/Xilinx_ISE_WebPACK

Once I got it running though, it was quite robust.

-- 
Dave Farrance

Article: 135471
Subject: Virtex-5 DDR2 DCI termination
From: Rob <BertyBooster@googlemail.com>
Date: Fri, 3 Oct 2008 01:41:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,

I've got a design with that interfaces to a wide (128 bit) DDR2 data
bus using a V5. I'm currently using the DCI feature to terminate all
of my signals, however because there are so many the power consumption
is unacceptably high.

I notice that a new IO standard has recently crept into the
documentation: SSTL18_II_T_DCI. Although the documentation on this is
lacking, it looks like this is supposed to remove the termination when
performing writes. However, when I tried to use it in my design,
implementation failed because apparently I can't mix
DIFF_SSTL18_II_DCI and SSTL18_II_T_DCI in the same bank.
Am I missing something here?? The Xilinx MIG design mandates that data
strobes and DQ lines must be in the same bank in order to make use of
the buffio feature. If the two standards can't be mixed then
SSTL18_II_T_DCI is effectively useless.

Has anyone had any experience with using this new standard?

cheers
Rob

Article: 135472
Subject: Re: Xilinx Timing constraint problems
From: Rob <BertyBooster@googlemail.com>
Date: Fri, 3 Oct 2008 01:53:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 1, 11:57=A0pm, "Greg Daughtry" <greg.daugh...@xilinx.com> wrote:
> Rob,
>
> Can you post a snippet of the failing path trace from TWR? =A0Is the cloc=
k
> requirement 4X of the TS_SYS_CLK timespec as this multicycle exception is
> indicating? =A0When you say the constraint is being ignored, what exactly=
 do
> you mean? =A0Are you looking for a header for the TS_MC_PHY_INIT_DATA_SEL=
_0,
> or are you seeing violations on paths that start from the
> */u_phy_init/u_ff_phy_init_data_sel instance?
>
> 'Greg
>
> Bring up this design in PlanAhead and search for the instances to make su=
re
> nothing simply like hierarchy separators is messing up the constraint?
>
> 'Greg
>
> "Rob" <BertyBoos...@googlemail.com> wrote in message
>
> news:014cfdc3-140e-49aa-aa0c-d2c5f76d1f7f@a1g2000hsb.googlegroups.com...
>
> > Hi all,
>
> > I'm having problems with ISE seemingly ignoring timing constraints set
> > in the UCF file. One of the constraints ignored comes from Xilinx's
> > MIG tool and looks like this:
>
> > INST "*/u_phy_init/u_ff_phy_init_data_sel" TNM =3D
> > "TNM_PHY_INIT_DATA_SEL";
> > TIMESPEC "TS_MC_PHY_INIT_DATA_SEL_0" =3D FROM "TNM_PHY_INIT_DATA_SEL" T=
O
> > FFS
> > "TS_SYS_CLK" * 4;
>
> > I'm not getting any errors, such as unable to locate nets, rather the
> > constraint seems ignored and looking in the timing report it is these
> > very paths that are failing (by a long way). I thought that if the
> > target nets don't exist then you get a translate error.
>
> > I am using partitions in the design. I've tried to do a build after a
> > "clean up project files" and the constraint is still ignored.
>
> > Any ideas?
>
> > Rob

Hi Greg,

Here's a snippet from the TWR file showing one of the failing paths:

=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=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=3D=3D
Timing constraint: TS_infastructure0_mem_clk_out_901 =3D PERIOD
TIMEGRP
"infastructure0_mem_clk_out_901" TS_infastructure0_dcm0_clkfx1
PHASE
1.25 ns HIGH 50%;

 1622 paths analyzed, 1354 endpoints analyzed, 513 failing endpoints
 513 timing errors detected. (513 setup errors, 0 hold errors)
 Minimum period is  10.276ns.
---------------------------------------------------------------------------=
-----
Slack:                  -1.319ns (requirement - (data path - clock
path skew + uncertainty))
  Source:               memory_domain0/u_ddr2_top/u_mem_if_top/
u_phy_top/u_phy_init/u_ff_phy_init_data_sel (FF)
  Destination:          memory_domain0/u_ddr2_top/u_mem_if_top/
u_phy_top/u_phy_write/wdf_data_r_102 (FF)
  Requirement:          1.250ns
  Data Path Delay:      2.030ns (Levels of Logic =3D 1)
  Clock Path Skew:      -0.234ns (2.558 - 2.792)
  Source Clock:         mem_clk_div2 rising at 0.000ns
  Destination Clock:    mem_clk90 rising at 1.250ns
  Clock Uncertainty:    0.305ns

  Clock Uncertainty:          0.305ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
    Total System Jitter (TSJ):  0.070ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.300ns
    Phase Error (PE):           0.120ns

  Maximum Data Path: memory_domain0/u_ddr2_top/u_mem_if_top/u_phy_top/
u_phy_init/u_ff_phy_init_data_sel to memory_domain0/u_ddr2_top/
u_mem_if_top/u_phy_top/u_phy_write/wdf_data_r_102
    Location             Delay type         Delay(ns)  Physical
Resource
                                                       Logical
Resource(s)
    -------------------------------------------------
-------------------
    SLICE_X42Y43.CQ      Tcko                  0.375   memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/phy_init_data_sel
                                                       memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/u_phy_init/u_ff_phy_init_data_sel
    SLICE_X43Y45.C5      net (fanout=3D282)      0.546   memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/phy_init_data_sel
    SLICE_X43Y45.C       Tilo                  0.086   memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/wr_data_rise<19>
                                                       memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/u_phy_write/
wdf_data_r_mux0001<101>11
    SLICE_X43Y50.SR      net (fanout=3D27)       0.575   memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/u_phy_write/N01
    SLICE_X43Y50.CLK     Tsrck                 0.448   memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/wr_data_rise<41>
                                                       memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/u_phy_write/wdf_data_r_102
    -------------------------------------------------
---------------------------
    Total                                      2.030ns (0.909ns logic,
1.121ns route)
                                                       (44.8% logic,
55.2% route)

I don't have Planahead (webpack only), but if I open the design up in
FPGA Editor I can find the named source register (as a BEL in a
slice). In the TWR file and in the FPGA Editor the path seems to
correctly match the constraint path.

Rob

Article: 135473
Subject: Re: floating point round off errors
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 03 Oct 2008 13:14:07 +0100
Links: << >>  << T >>  << A >>
On Thu, 02 Oct 2008 19:14:28 -0800, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>Brian Drummond wrote:
>> At this point there are two aspects to consider:
...
>> (2) the importance of errors in the application anyway. (It may be worth
>> using higher precision internally in critical areas).
>
>The nice thing about verilog implementations is that you
>can easily add bits, even one or two.  That is hard on a
>processor with fixed sized registers.

Verilog and VHDL both.

How well would Verilog work for writing a high level model using actual
floats (not synthesisable), for comparison with the hardware
implementation? Make the testbench self-checking without external files.
That is the obvious approach to me in VHDL, but I don't know if it would
transfer to Verilog. However it is also not immune to problems of
precision; most VHDL implementations I've come across use double
precision but it isn't guaranteed. (So the testbench must also check
itself!)

>> If the Verilog implementation must be correct, you will need a reference
>> implementation in which every operation is known to be correct to single
>> precision (the difficult bit, in C!), and test for bitwise identical
>> results.
>
>There might be some compilers that will force single precision
>between every operation.

That would be useful. Otherwise you have to force the conversion
manually; possible but unnecessarily hard work.
- Brian

Article: 135474
Subject: Re: WEBPACK for linux
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 03 Oct 2008 13:19:31 +0100
Links: << >>  << T >>  << A >>
On Fri, 03 Oct 2008 08:03:10 GMT, Dave Farrance
<DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> wrote:

>Jon Elson <jmelson@wustl.edu> wrote:
>
>>beky4kr@gmail.com wrote:
>>> A few years ago I downloaded the WEBPACK for linux.
>>> I checked recently in http://www.xilinx.com/support/download/index.htm
>>> and it seems the free version is only for windows.
>>> 
>>> Does xilinx stop to give it for free (the linux version).
>>They still have the free Linux version, for 32-bit architecture ONLY!
>>If you have a 64-bit system, there apparently is a way to make it work, 
>>too.  I didn't want to do that much hacking, and we have a site license 
>>for the "real thing".
>
>I've not tried this because I'm still on 32-bits, but I understand that
>you need to install the 64-bit distro's 32-bit compatibility libraries.

That's what I did (on OpenSuse 11 64-bit) and it worked. 

I also needed to disable the abort-on-Linux64 test in the "Setup" shell
script, on the basis that this test didn't know about the 32-bit
compatibility libraries, but that was trivial.

>As to how easy the free Webpack for Linux is to get working in general,
>you might need to do a *little* hacking to get it to work, if my
>experience of installing it on Mandriva 2006 a couple of years back is
>anything to go by...

Other than the above; I didn't have to do anything. Other distributions
may vary. (Caveat: I haven't tried installing USB cables yet)

>Once I got it running though, it was quite robust.

Agreed.

- Brian



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search