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

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

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

Custom Search

Messages from 86475

Article: 86475
Subject: APEX 20K PLL
From: "alpha" <zhg.liu@gmail.com>
Date: 28 Jun 2005 13:56:15 -0700
Links: << >>  << T >>  << A >>
Hi;

Can anyone give a instruction on how to implement "altclklock" (PLL)
for EP20K200E fpga in details? PLL input clock is 33Mhz. I want PLL's
output clock0 is 33Mhz and clock1 is 33/2Mhz, using internal feedback.
(No external feed back).

I can not make it compiled in QuartusII 3. The error message is
something like "locked output must drive (positively) only clock pin or
port".

Thanks


--ZL


Article: 86476
Subject: Re: Two Verilog FSM style compare
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 28 Jun 2005 15:01:47 -0700
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> In article <3iaqseFkg3klU1@individual.net>,
> Mike Treseler  <mike_treseler@comcast.net> wrote:
> >Joseph H Allen wrote:
>
> >> (if only you could use the blocking assign output as an input to another
> >> clocked always block... but you can't).
>
> >True. A blocking assignment is like a local variable.
> >However, you *can* make the always block as big
> >as you like with as many registers as you like.
>
> So... you should make the entire design in just one always block? :-)
>
> Verilog is a crazy language.  I write code in order, but you really don't
> have to:
>
> // Move ~c into a
>
> always @(b or c)
>   begin
>     a = b;
>     b = c;
>     b = ~c;
>   end
>
> A change in c triggers the always block: ~c moved into b.  Change in b
> retriggers the always block: b moved into a.  I guess synthesis tools have
> to make a dependency graph to figure out the dataflow.

That sort of construct, with blocking variables, is bound to bite you
in the ass!

-a


Article: 86477
Subject: Re: Good FPGA for an encryptor
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Tue, 28 Jun 2005 23:10:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <1119944158.361799.204400@g43g2000cwa.googlegroups.com>,
 <allanherriman@hotmail.com> wrote:
>>Piotr wants to do crypto in the FPGA.
>
>'Doing crypto' does not imply a requirement for bitstream encryption.

Actually, it often helps.  You can use the bitstream encryption, IF
your encrypted bitstream knows the key and how to modify the encrypted
bitfile and encryption-loader key, to store a good amount of
nonvolatile key material in a system which should be (ideally) equally
hard as breaking the bitfile encryption.

See pages 16-18 in particular in this talk I did:
http://www.icsi.berkeley.edu/~nweaver/security_talk_fpga.ppt
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 86478
Subject: Re: Two Verilog FSM style compare
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Tue, 28 Jun 2005 23:21:30 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <1119994796.827887.175030@g14g2000cwa.googlegroups.com>,
Andy Peters <Bassman59a@yahoo.com> wrote:
>Joseph H Allen wrote:
>> In article <3iaqseFkg3klU1@individual.net>,
>> Mike Treseler  <mike_treseler@comcast.net> wrote:
>> >Joseph H Allen wrote:
>>
>> >> (if only you could use the blocking assign output as an input to another
>> >> clocked always block... but you can't).
>>
>> >True. A blocking assignment is like a local variable.
>> >However, you *can* make the always block as big
>> >as you like with as many registers as you like.
>>
>> So... you should make the entire design in just one always block? :-)
>>
>> Verilog is a crazy language.  I write code in order, but you really don't
>> have to:
>>
>> // Move ~c into a
>>
>> always @(b or c)
>>   begin
>>     a = b;
>>     b = c;
>>     b = ~c;
>>   end
>>
>> A change in c triggers the always block: ~c moved into b.  Change in b
>> retriggers the always block: b moved into a.  I guess synthesis tools have
>> to make a dependency graph to figure out the dataflow.
>
>That sort of construct, with blocking variables, is bound to bite you
>in the ass!

I know someone who never ever makes more than one assignment to a variable
in a single always block (no defaulting at all for maximized typing). 
Instead he makes an assignment to each register in each decision branch, so
that you get one decision branch or less per editor screen: tiny state
machines end up being 10,000 lines. He also uses non-blocking assigns in
combinatorial always blocks, which is just weird.  He also does the out of
order thing above: there will be some code at the end whose outputs are used
by a state machine case at the top.  Finally, he never uses "if": only
"casex", always with "// synthesis full_case parallel_case".  Usually, the
casex's are three levels deep. Finally he always uses positional arguments
in instantiations for modules with 100s of signals (sometimes the wire names
even match the port names).  Oh yeah: he never uses parameters- only
`defines all in one giant include file, even for state machine states. 
There is not one comment in 100,000 lines of code.  I am not making this up.

Hmm... should I just edit the code and get it over with or should I make
that Verilog refactoring program I always knew would come in handy...
hmm...

Well on the positive side, his_signals_look_like_this, NotLikeThis.  He uses
the default emacs verilog mode, so the begins and ends are at the same
indentation level.  Some other person's annoying code looks like this:

if (theSignal) begin
  stuff
end // if (theSignal)

Whoever wrote the elisp macros which put in these useless VHDLish comments
should be shot.  His files all begin with a long boilerplate comment with no
useful information (but he does put comments in his code, unlike the first
person).

Sorry, I'll stop ranting now.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 86479
Subject: Xilinx Virtex 4 device technology
From: "Amora" <amrahmadain@gmail.com>
Date: 28 Jun 2005 16:28:46 -0700
Links: << >>  << T >>  << A >>
Does anybody happen to know the if Xilinx Virex 4 and/or the QPRO
familiy of devices are fabricated using the fully depleted SOI (FD SOI)
technology as opposed to the traditional bulk CMOS?

Thanks,

Amr Ahmadain


Article: 86480
Subject: Soft core for MPEG codec
From: "sps" <sanjaypratapsingh@gmail.com>
Date: 28 Jun 2005 16:40:36 -0700
Links: << >>  << T >>  << A >>
Hi,

I am looking for free MPEG soft-core to be implemented in FPGA.Can
anybody give some pointers?

Thanx for the help.

Regards

sps


Article: 86481
Subject: Re: Two Verilog FSM style compare
From: "John McGrath" <tails4e@gmail.com>
Date: 28 Jun 2005 17:48:23 -0700
Links: << >>  << T >>  << A >>
Hi Joseph..
First this guy works for a company and is allowed to get away with it?
It sounds like a true nightmare to even look at his code, let alone
interpret it!

But on the using blocking assingments in a non-clocked always block -
this was actually recommended to me on an advanced verilog course. The
only reason being given that it was more efficient to simulate. (don't
ask me to prove it!). It seems that it can be shown, for non clocked
always blocks the always event is triggered less times when blocking is
used. so at least he's doing *one* thing right. :)

Joseph H Allen wrote:
> In article <1119994796.827887.175030@g14g2000cwa.googlegroups.com>,
> Andy Peters <Bassman59a@yahoo.com> wrote:
> >Joseph H Allen wrote:
> >> In article <3iaqseFkg3klU1@individual.net>,
> >> Mike Treseler  <mike_treseler@comcast.net> wrote:
> >> >Joseph H Allen wrote:
> >>
> >> >> (if only you could use the blocking assign output as an input to another
> >> >> clocked always block... but you can't).
> >>
> >> >True. A blocking assignment is like a local variable.
> >> >However, you *can* make the always block as big
> >> >as you like with as many registers as you like.
> >>
> >> So... you should make the entire design in just one always block? :-)
> >>
> >> Verilog is a crazy language.  I write code in order, but you really don't
> >> have to:
> >>
> >> // Move ~c into a
> >>
> >> always @(b or c)
> >>   begin
> >>     a = b;
> >>     b = c;
> >>     b = ~c;
> >>   end
> >>
> >> A change in c triggers the always block: ~c moved into b.  Change in b
> >> retriggers the always block: b moved into a.  I guess synthesis tools have
> >> to make a dependency graph to figure out the dataflow.
> >
> >That sort of construct, with blocking variables, is bound to bite you
> >in the ass!
>
> I know someone who never ever makes more than one assignment to a variable
> in a single always block (no defaulting at all for maximized typing).
> Instead he makes an assignment to each register in each decision branch, so
> that you get one decision branch or less per editor screen: tiny state
> machines end up being 10,000 lines. He also uses non-blocking assigns in
> combinatorial always blocks, which is just weird.  He also does the out of
> order thing above: there will be some code at the end whose outputs are used
> by a state machine case at the top.  Finally, he never uses "if": only
> "casex", always with "// synthesis full_case parallel_case".  Usually, the
> casex's are three levels deep. Finally he always uses positional arguments
> in instantiations for modules with 100s of signals (sometimes the wire names
> even match the port names).  Oh yeah: he never uses parameters- only
> `defines all in one giant include file, even for state machine states.
> There is not one comment in 100,000 lines of code.  I am not making this up.
>
> Hmm... should I just edit the code and get it over with or should I make
> that Verilog refactoring program I always knew would come in handy...
> hmm...
>
> Well on the positive side, his_signals_look_like_this, NotLikeThis.  He uses
> the default emacs verilog mode, so the begins and ends are at the same
> indentation level.  Some other person's annoying code looks like this:
>
> if (theSignal) begin
>   stuff
> end // if (theSignal)
>
> Whoever wrote the elisp macros which put in these useless VHDLish comments
> should be shot.  His files all begin with a long boilerplate comment with no
> useful information (but he does put comments in his code, unlike the first
> person).
>
> Sorry, I'll stop ranting now.
> --
> /*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
> int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
> +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
> ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}


Article: 86482
Subject: Re: V4 and NBTI question, again..
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Wed, 29 Jun 2005 01:20:57 GMT
Links: << >>  << T >>  << A >>
Ray - 

Thanks for that very useful description.

Bob Perlman
Cambrian Design Works

On Tue, 28 Jun 2005 16:19:47 -0400, Ray Andraka <ray@andraka.com>
wrote:

>>
>Antti, you can download the verilog macro from the website.  In order to 
>get the VHDL one, you have to ask.  The VHDL one is not really ready, it 
>has a number of things in it that won't synthesize properly under 
>synplify.  Both versions use a pair of counters that are asynchronously 
>reset by a level on the incoming clock.  The design has some potential 
>metastability hazards, and because of the set up, I suspect won't detect 
>clock presence reliably with higher frequency clocks.  The design is 
>also a little on the resource intensive side, and can be made quite a 
>bit smaller by rethinking the clock detection and using a shift register 
>for saving the calibration constants rather than lut ram (eliminates the 
>addressing and decodes).  The other issue is that you really need to 
>jump through hoops to keep the macro from getting trimmed out during map 
>if it is for an unused DCM.  The patch in 7.1 puts the macro in after 
>map, so that it doesn't get trimmed out, however, if the other gotchas 
>in 7.1 are forcing you to 6.3 then you need to come up with a null DCM 
>on your own (there is supposedly a strategic patch for 6.3, but I have 
>not been able to find it yet)..  Either way, you need to load a 
>bitstream right away to avoid the NBTI all together.
>
>The function of the macro is actually rather simple.  Basically, it has 
>a clock sense circuit that detects missing clock in and missing feedback 
>(you don't need the feedback detect logic if you are doing the feedback 
>inside the FPGA).  The sense logic in the macro is a little hokey, and 
>uses more area than it needs to.  A state machine basically waits for no 
>clock to be detected, then it reads the DRP port on the DCM at addresses 
>42h, 51h and 4Eh and stores them in LUT RAM.  It then writes "0000" to 
>4E, apparently this shuts off the DCM outputs, and then it cycles 
>through 4 states in sequence that write values alternately to 42 and 
>51.  These apparently tweak the internal calibration to keep the delay 
>lines toggling.  It continues to cycle through those 4 states until 
>clock is restored (or reset is released).  When that happens, it writes 
>the stored values for 42,51 and 4E back into the DRP port, triggers a 
>DCM reset and goes back to the initial state.  I rewrote the macro using 
>srl16s for the drp value storage (this eliminates the addressing logic), 
>and used my own clock detection circuit that cuts the clock detection 
>circut size to less than 30% of the original.  I also cleaned up the 
>state machine so that it is a single machine rather than a 
>conglomeration of smaller machines. The clock for the detect circuit is 
>a ring oscillator divided down to about 8 Mhz.  Xilinx routes it on 
>local routing rather than on a clock net, probably to avoid using up 
>clock nets for designs that use a lot of clocks.  I also made a null DCM 
>macro which basically removes the clock detect logic, and alters the 
>reset logic.


Article: 86483
Subject: Re: Xilinx Virtex 4 device technology
From: austin <austin@xilinx.com>
Date: Tue, 28 Jun 2005 18:40:58 -0700
Links: << >>  << T >>  << A >>
Amora,

We do not use SOI in any of our products.

Austin

Amora wrote:

> Does anybody happen to know the if Xilinx Virex 4 and/or the QPRO
> familiy of devices are fabricated using the fully depleted SOI (FD SOI)
> technology as opposed to the traditional bulk CMOS?
> 
> Thanks,
> 
> Amr Ahmadain
> 

Article: 86484
Subject: Re: USB 2.0 core with 1.1 tranceiver problem
From: michaeldre@gmx.de (Michael Dreschmann)
Date: Wed, 29 Jun 2005 02:05:57 GMT
Links: << >>  << T >>  << A >>
Hello,

thanks for the explanation, rudi. If I need a small core sometime in
the future, I will retry the 1.1 core with that modifications.
But for know I got the 2.0 core working with a 1.1 transceiver and I
think that has a few advantages if you don't have to look at every
used gate...
I just had to increase the timeout values for DATA after OUT token and
ACK after IN token (link mentioned in an earlier post). For DATA after
OUT token a value of 1.6us works but for the ACK after IN token it
works only if I use something at 4.2 us. Does anyone know if these
values are ok?
But if have an other (little) problem know:
Is there any way to detect the host got an stall handshake after I
have set the endpoint to halt mode?
The problem is, if a request on EP0 isn't supported I have to generate
stall handshakes until the next setup packet. But if I halt the pipe I
don't know when the host gets the stall handshake and I have to clear
the halt. Unfortunately EP0 doesn't accept the next setup packet when
it is halt. (something it should do according to the USB spec). So I
can't just wait until I receive the next packet that probably would be
a setup packet.

Thanks for your help,
 Michael

Article: 86485
Subject: Re: proth siever in FPGA?
From: "Andrew FPGA" <andrew.newsgroup@gmail.com>
Date: 28 Jun 2005 20:41:34 -0700
Links: << >>  << T >>  << A >>
Hi Alex,
I don't know anything about "seiving" but  it sounds like a good first
project - the operations inside your loop are straight forward to
implement in FPGA logic (comparison/shifting/add/subtract). Although
you didn't state it, I'm assuming the overall goal is to achieve the
fastest throughtput possible given the starter kit hardware
constaints?, i.e. maximise sieved numbers per second.

Why do you feel you can't do one iteration of that loop per clock
cycle? If you pipeline your logic you will get through the loop once
per clock cycle, but there will be a latency of 2,3, 4 etc clock cycles
depending on how deeply you need to pipeline.  You should be able to
achieve well above 50MHz, the max clock rate will ultimately depend on
how deeply you pipeline.

I don't necessarily agree with Ben's statement that the memory
(external SRAM?) bandwidth will be the limiting factor on throughput.
Say each siever uses 100 slices and a XC3S200 provides 1920 slices,
then you can have 19 sievers operating in parallel.  If each siever
takes 1 second to complete the algorithm then every second you need 19x
( p read, r read, n write) which is a trivial amount of bandwidth.

If speed is your goal then optimise the algorithm first (although I
guess you will need some experience and knowledge of the hardware/FPGA
before you can do this). Maybe I didn't understand the algorithm, but
if the loop runs to completion 99.9% of the time then there must be a
way of exploiting this? Wouldn't it be better to first do a coarse run
through by going e.g r<<2, and  n+2 etc Well, make it as "coarse" as
possible. 

Regards
Andrew


Article: 86486
Subject: Re: Lattice LFEC
From: vbetz@altera.com
Date: 28 Jun 2005 20:47:07 -0700
Links: << >>  << T >>  << A >>
For those reading this thread, Richard sent us the t80 archive (thanks
Richard), so we could investigate this. The short answer is that the
core didn't have a timing constraint set, so recent versions of Quartus
(4.1 and later) just work to achieve routability, and do not fully
optimize its timing. Setting an aggressive clock period constraint
dramatically speeds up the core when run through Quartus.

Details:

I compiled the t80a core in Quartus II 5.0 SP1, and
achieved 42.74 MHz, which matches Richard's result.  However, I noticed
that
there are no timing requirements set -- in that case Quartus will
try to compile the design as fast as possible, and will not fully
optimize the design for timing.

I went to Assignments->Timing Settings and set "Default required Fmax"
to 100 MHz.  Then I recompiled.

With that assignment, Quartus achieves a frequency of 75.53 MHz for
this
design.

It is a general rule that you should set an aggressive (unachievable)
timing assignment when you want to see how fast a design can go.
Alternatively, you can choose Settings->Fitter Settings->Standard Fit,
which essentially makes the most common type of unachievable timing
requirement (Fmax on all clocks) automatically for you.

To get even more speed, you can also turn on physical synthesis (all
options)
under Assignments->Settings->Physical Synthesis Optimizations. On this
design, turning physical synthesis on (+ having a 100 MHz default Fmax)
yields a speed of 83.43 MHz.

Best regards,

Vaughn Betz
A;tera
[v b e t z (at) altera.com]


Article: 86487
Subject: Re: Good FPGA for an encryptor
From: vbetz@altera.com
Date: 28 Jun 2005 20:56:19 -0700
Links: << >>  << T >>  << A >>
Hi Piotr,

Not sure if this would meet your needs or not, but MAX II has on-chip
flash where you could store the key.
The devices aren't as big as Cyclone though -- ~2k LEs is the biggest
MAX II device, and it doesn't have on-chip embedded RAM blocks.  So
whether MAX II is a good fit depends on if you need the density &
on-chip RAM of Cyclone as well as the on-chip flash that MAX II has.

Regards,

Vaughn
Altera
[v b e t z (at) altera.com]


Article: 86488
Subject: Clock buffers on the Viretx E
From: "vssumesh" <vssumesh_asic@yahoo.com>
Date: 28 Jun 2005 22:41:51 -0700
Links: << >>  << T >>  << A >>
The xilinx tool is forcing the external clock input to the internal
clock buffer. And this buffer can take input from only selected
channels. This restricts the input clocks to some clock pins. How can
reassign it with the tool.
1. is there any problem in doing this
2. How can i achive this.
i want to route a low frequency clock through normal i/o pad.


Article: 86489
Subject: Re: FPGA :FFT Core in Xilinx
From: bijoy <pbijoy@rediffmail.com>
Date: Tue, 28 Jun 2005 23:51:21 -0700
Links: << >>  << T >>  << A >>
Hi

Do you have any test project for FFT core validation ?

could you pls share it if possible.

am facing some problem in using xilinx fft core. as the output produced does not match with matlab output regards bijoy

Article: 86490
Subject: Re: Good FPGA for an encryptor
From: Kolja Sulimma <news@sulimma.de>
Date: Wed, 29 Jun 2005 08:52:17 +0200
Links: << >>  << T >>  << A >>
Piotr Wyderski schrieb:
> Hello,
> 
> I would like to build a 1GBit/s data encryptor/decryptor using
> an FPGA chip, but I have a big problem with an appropriate
> chip. It should contain about 3000LE, 70 IO pins and at least
> 12 dual-port RAM blocks (I need two read ports per block) configurable
> as 512x8 banks. Additionally, it should be Flash-based or SRAM
> -based with encrypted bitstream. And must be cheap. Here are the
> options I know of:

Hmm. As I understand it, if the algorithm ist known, a skilled attacker
will find the key with differential power analysis within hours if he
can take the board to the lab.
So you do not gain much by an encrypted bitstreams or even a OTP part.
You only prevent amateurs from breaking your chip, but they can always
pay an expert.

You can ofcourse invent your on algorithm and keep it secret, but I
doubt that this will be any more secure.

The only way to be safe is to make sure the key never ands up in a
hostile lab, for example by carrying it around on a keychain.

Kolja Sulimma

Article: 86491
Subject: Linux 2.6 on the Xilinx ML310 board
From: "Sven Gowal" <sgowal@gmail.com>
Date: 29 Jun 2005 00:46:34 -0700
Links: << >>  << T >>  << A >>
I haven't been able to find any useful resources on how to install the
new Linux 2.6 kernel on the ML310 board.

Does anyone have an idea on how to do that ? (which drivers, patches I
would have to use ?)

Thanks a lot,
Sven


Article: 86492
Subject: Re: Good FPGA for an encryptor
From: David Brown <david@westcontrol.removethisbit.com>
Date: Wed, 29 Jun 2005 09:55:59 +0200
Links: << >>  << T >>  << A >>
Kolja Sulimma wrote:
> Piotr Wyderski schrieb:
> 
>>Hello,
>>
>>I would like to build a 1GBit/s data encryptor/decryptor using
>>an FPGA chip, but I have a big problem with an appropriate
>>chip. It should contain about 3000LE, 70 IO pins and at least
>>12 dual-port RAM blocks (I need two read ports per block) configurable
>>as 512x8 banks. Additionally, it should be Flash-based or SRAM
>>-based with encrypted bitstream. And must be cheap. Here are the
>>options I know of:
> 
> 
> Hmm. As I understand it, if the algorithm ist known, a skilled attacker
> will find the key with differential power analysis within hours if he
> can take the board to the lab.
> So you do not gain much by an encrypted bitstreams or even a OTP part.
> You only prevent amateurs from breaking your chip, but they can always
> pay an expert.
> 
> You can ofcourse invent your on algorithm and keep it secret, but I
> doubt that this will be any more secure.
> 
> The only way to be safe is to make sure the key never ands up in a
> hostile lab, for example by carrying it around on a keychain.
> 
> Kolja Sulimma

I'm not an expert (I'm not even an amateur) in cryptography, but can you 
not fool differential power analysis by adding extra logic to cause 
unpredictable switching to swamp any useful power analysis?


Article: 86493
Subject: xp3/xp6 in ispLever
From: Jedi <me@aol.com>
Date: Wed, 29 Jun 2005 08:05:52 GMT
Links: << >>  << T >>  << A >>
Hello

Does someone knows when XP3/6 devices can be used in ispLever Base 5.0?
Lattice said that samples for them should already be available now
and I need to verify in design before doing my XP3/6 PacMan design (o;


rick

Article: 86494
Subject: Re: Chess & FPGAs
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Wed, 29 Jun 2005 10:07:17 +0200
Links: << >>  << T >>  << A >>
>
>> looks like Chess and FPGAs are making news all around, esp Hydra,
>> Alphadata,
>>
>> and xcell article
>>
>> http://www.xilinx.com/publications/xcellonline/xcell_53/xc_hydra53.htm
>
> Interesting - but no info on the size of the Knowledge database.
>
>> How long before someone builds a lowend version spartan3 version with
>> cpu and chess engine inside, no external H8 etc. What would the ELO
>> ranking be?
>
>  You mean truly one chip, or with off-chip database storage ?
>
>  Once they are able to claim to better the best human players, then
> the goals can move to :
>

They can claim it right now: Hydra won 5.5 to 0.5 against Adams (Nr. 1
in Britain) last week:
http://tournament.hydrachess.com/

Looks like the game Man vs Machine is over.

Martin 



Article: 86495
Subject: Small FPGA
From: Sylvain Munaut <com.246tNt@tnt>
Date: Wed, 29 Jun 2005 10:20:12 +0200
Links: << >>  << T >>  << A >>
Hello,

I'd like to find a really small FPGA that I could solder by hand,
like in a VQ44 or VQ64 package. Ideally, it should only require a
single 3.3v supply, but a dual supply core/io would be OK too if
really necessary.

I really don't need many logic probably as few as 500 LE.

I tried the XC9500 CPLD line from xilinx but it seems my application
doesn't fit CPLD well, I basically need counters, registers and
mux.


	Sylvain

Article: 86496
Subject: Re: Small FPGA
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 29 Jun 2005 10:49:34 +0200
Links: << >>  << T >>  << A >>
"Sylvain Munaut" <com.246tNt@tnt> schrieb im Newsbeitrag
news:42c25994$0$28322$ba620e4c@news.skynet.be...
> Hello,
>
> I'd like to find a really small FPGA that I could solder by hand,
> like in a VQ44 or VQ64 package. Ideally, it should only require a
> single 3.3v supply, but a dual supply core/io would be OK too if
> really necessary.
>
> I really don't need many logic probably as few as 500 LE.
>
> I tried the XC9500 CPLD line from xilinx but it seems my application
> doesn't fit CPLD well, I basically need counters, registers and
> mux.
>
> Sylvain

there unfortunatly arent any FPGAs in VQ44 or VQ64 package :(
the smalles FPGA packages (non BGA) are TQFP100 what is pretty much larger
already.
by had you can actually solder very nicely also QFN packages but there are
virtually no FPGA in QFN at all,

actel A3P030 should be offered in QN132 (I assume its QFN not BGA!), but
ASFAIK it is not available

Atmels FPSLIC is coming to small 8by8 package, but again its not available
and I think its BGA (there is not even info about this)

so everything that has smaller PCB footprint than TQFP100 is already in BGA
or not available

you should try to fit your design into PLD, you have better luck to find
smaller PLD devices, but well sure the PLD prices go up much more faster
when you need more macrocells.

the 'design for fit' for PLDs s totally different from FPGA, so by doing
special optimization for PLD you may fit way more into a PLD then you think

two examples from my experience

1) a complete MMC card controller that support MMC protocol (not SPI) and
loads the all bits from MMC card, it takes 20 PLD macrocells (in coolrunner,
21 in XC9500), that is way less than, well if you think its only 20 flip
flops! this design is specilla optimized for PLD

2) recently I was asked to display a textual message on intelligent display,
using a PLD, well the PLD was already full having a macrocells free, but to
my own surprise the display of an text string involved only an addition of 1
flip flop, well this one flip re-targetted most of the existing macrocells
to have secondary function...

counters and muxes and registers are quite easy in PLD, but the amount of
registers is sure limited, all flip flops have a way higher 'price' than the
flipp flops in FPGA

hm, the larger PLD are also in packages larger than VQ64 :( so there isnt
much that fits your requirements

I would go with MAX2 in TQFP100, but if that package is too large than you
have to wait for APA030 QN132, or maybe there is something else coming out
sooner, lattice promised some new PLD devices to be announced 'after your
summer vaccation'

Antti













Article: 86497
Subject: ADPLL for NRZ
From: "Alex" <jovajsha@yahoo.com>
Date: Wed, 29 Jun 2005 10:29:01 +0100
Links: << >>  << T >>  << A >>
Hi,

I am trying to find some literature of how to design All Digital PLL which
would extract clock from NRZ signal. The main problem here is that zero
crossing is not present every bit. Also, does anyone know how to set digital
filter parameters (in practice) based on loop bandwidth, tracking band and
parameters like that? Thanks.

Alex




Article: 86498
Subject: Re: Small FPGA
From: Sylvain Munaut <com.246tNt@tnt>
Date: Wed, 29 Jun 2005 11:56:15 +0200
Links: << >>  << T >>  << A >>
Hi Antti

> you should try to fit your design into PLD, you have better luck to find
> smaller PLD devices, but well sure the PLD prices go up much more faster
> when you need more macrocells.
> 
> the 'design for fit' for PLDs s totally different from FPGA, so by doing
> special optimization for PLD you may fit way more into a PLD then you think

Yes, indeed my "style" is more based on FPGA experience.
What would be the "CPLD" way to code a debouncer ?


> I would go with MAX2 in TQFP100, but if that package is too large than you
> have to wait for APA030 QN132, or maybe there is something else coming out
> sooner, lattice promised some new PLD devices to be announced 'after your
> summer vaccation'

I'm kind of in a hurry ;)


Thanks for the insight,


	Sylvain

Article: 86499
Subject: Re: Small FPGA
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 29 Jun 2005 12:12:11 +0200
Links: << >>  << T >>  << A >>
"Sylvain Munaut" <com.246tNt@tnt> schrieb im Newsbeitrag
news:42c27017$0$23344$ba620e4c@news.skynet.be...
> Hi Antti
>
> > you should try to fit your design into PLD, you have better luck to find
> > smaller PLD devices, but well sure the PLD prices go up much more faster
> > when you need more macrocells.
> >
> > the 'design for fit' for PLDs s totally different from FPGA, so by doing
> > special optimization for PLD you may fit way more into a PLD then you
think
>
> Yes, indeed my "style" is more based on FPGA experience.
> What would be the "CPLD" way to code a debouncer ?

not everything can be pld optimized. if you only have 100mhz clock and need
some low frequency then you need some amount of flip flops to implement the
counter.

so if you need to debounce a mechanical switch you might need lots of flip
flops (assuming only high frequency clock is available) - a 'saving' in PLD
would be to have separate RC oscillator to get low frequency needed for
debounce

the most savings in PLD come from resources sharing, as example if you have
a need a counter and and shift register, but they are never active at same
time, you can use the same macrocells, that is 8 bit counter and 8 bit shift
register consumes 8 PLD macrocells (but they are not useable at the same
time).

the 500LE (if that is LE as in Altera) would defenetly fit into a PLD but
the LE to PLD macrocell ratio depends on the application, if there is really
lots of (wide) logic, 500LEs could be even as small as 72 PLD macrocells (eg
fit XC9572 VQ64), if the design is register rich then the ratio would be 1:1

note that altera MAX2 is not a PLD, but simplified FPGA, so the LE to MAX2
cell is 1:1 there is no reduction

 > > I would go with MAX2 in TQFP100, but if that package is too large than
you
> > have to wait for APA030 QN132, or maybe there is something else coming
out
> > sooner, lattice promised some new PLD devices to be announced 'after
your
> > summer vaccation'
>
> I'm kind of in a hurry ;)
>
>
> Thanks for the insight,
>
>
> Sylvain

if in hurry then you must either use TQFP100 package or BGA

Antti









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

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

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

Custom Search