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
2019JanFebMar2019

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 43150

Article: 43150
Subject: Re: Architecture for high-level reconfigurable computing
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Tue, 14 May 2002 23:49:53 +0100
Links: << >>  << T >>  << A >>
Steve Casselman wrote
> Yes the other way in C is to have functions that run in parallel like
> threads. The compiler must be smart enough to infer real parallel hardware.
> Also if you take the list operator and define the behavior as fully parallel
> then C does not seem sequential.


Handel-C does that - the good bits of CSP, with C-flavored syntax.
And it still ain't quite what the market wants.  Not even old
Occam hackers like me.

Though maybe if I was given a chunk of C to "accellerate"...
Even then, I would need to be convinced that C->Handel is way
faster than C->VHDL for anyone except a Handel enthusiast.










Article: 43151
Subject: Heat Sink/Fan for XC2V3000-4BF957
From: "William L Hunter Jr" <wlhunterjr@attbi.com>
Date: Tue, 14 May 2002 22:58:03 GMT
Links: << >>  << T >>  << A >>
Does anybody know what type of cooling is available for a XC2V3000-4BF957?
Any good or bad experiences?

Thanks in advance
Bill



Article: 43152
Subject: Re: Driving high speed external devices from an FPGA
From: kayrock66@yahoo.com (Jay)
Date: 14 May 2002 15:58:57 -0700
Links: << >>  << T >>  << A >>
What you are doing is similar to driving SDRAM external, and there is
an app not about this.  Sounds like you're on the right track with the
DLL.  This will guarantee the phase of the internal and external
clocks are aligned.  If you're worried about having a delay spread
through the IOB's, register your data in the IOB output flops.  You
can push the data back and forth relative to the clock by varying the
configuration of the IOB (slew rate, I/O standard, drive, delay,
etc...)

Regards!

mr_bert_wibble@hotmail.com (Bert Wibble) wrote in message news:<a51d2f02.0205140623.62f15b8c@posting.google.com>...
> Hello all,
> 
> Does anyone have any experience in driving external high speed devices
> from an
> FPGA, in particular a DAC ?
> To put some flesh around this, I am attempting to drive a 10bit DAC
> from an
> FPGA at 160MHz. The DAC and the FPGA share a common clock - but at
> this speed
> their exact phase allignment is not known.
> Internal to the FPGA (Xilinx), I am using a DLL/clock net to lock the
> internal
> clock to the external one.
> I am also happy with the idea that there will be a delay spread of the
> data through the FPGA IOB/pad combo.
> 
> My question is - does anyone have any useful ideas on how I can
> guarantee to
> meet the setup and hold times of my DAC given the uncertainties of the
> clock
> delays ?
> There seems to be very little information around on this topic - is
> this
> another "black art" area ?
> 
> Thanks in advance,
> Bert

Article: 43153
Subject: Re: Bus arbiter with low latency
From: kayrock66@yahoo.com (Jay)
Date: 14 May 2002 16:05:57 -0700
Links: << >>  << T >>  << A >>
What was your problem with a combinational ACK?  This was the way I
solved that problem.  That ACK eventually ends up (through logic) at
the at the d pin of a synchronous flop so what's the issue?

Regards

jetmarc@hotmail.com (jetmarc) wrote in message news:<af3f5bb5.0205140349.383e56e0@posting.google.com>...
> Hi.  I'm fairly new to programmable logic.  Now I'm working
> on a bus arbiter, but can't come up with a good solution.
> 
> My first design works like this:
> 
> Clock cycle 1:  peripherial requests bus (REQ=1).
> Clock cycle 2:  arbiter makes decision and gives bus (ACK=1).
> Clock cycle 3:  peripherial releases request (REQ=0) and
>                 does a non-waitstate access with the bus.
> 
> The problem is about latency.  A single access takes 3 cycles.
> Peripherials that react on an external WAITSTATE signal do not
> know how long the access takes, and can not release REQ in
> advance.  They waste yet another cycle by requesting more bus
> slots than necessary.
> 
> But how can I speed this up?  I thought about clocking the
> ACK signal on the opposite clock edge than the rest of the
> system. That would make ACK arrive before the end of the
> REQuest.  A single access reduces to 2 clock cycles instead
> of 3.
> 
> But doesn't this reduce the whole design speed?  To make
> signals arrive okay in 1/2 clock period, I have to reduce
> the total system clock to 1/2 of its otherwise possible
> maximum.  Right or wrong?
> 
> And isn't this almost as bad as using a non-clocked ACK,
> with combinatorial logic only?   I made bad experience
> already with non-clocked signals.  Simply removing the
> clock made a previous design flakey, although the signals
> were very simple.  My toolchain seems to definately
> prefer clocked signals.
> 
> Can you please give advice on how to reduce the REQ/ACK
> latency in bus arbiters, and/or point me to appnotes and
> papers about this topic?
> 
> Thank you very much!
> 
> Marc

Article: 43154
Subject: Re: Architecture for high-level reconfigurable computing
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 15 May 2002 11:24:58 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Jim,
> 
> Yup.  Been there, done that.  No news.  Nothing there.

 You mean it has more 'qualifications' and 'vaporware nature' 
than suggested by their marketing info :)

-jg

Article: 43155
Subject: Re: Altera/Quartus II: unconditional loop?
From: Ted Bronson <tedbronson@hotmail.com>
Date: Tue, 14 May 2002 19:39:55 -0400
Links: << >>  << T >>  << A >>


Dines Justesen wrote:

>>I'm a bit new to all this... why doesn't the Quartus II
>>support the "loop <body> end loop;" loop??
>>
> 
> When synthesizing VHDL loops inside a process will result in the logic 
> inside the loop being repeated as many time as the code is looped. So if 
> you loop a statement which generates and adder 16 times, it will generally 
> create 16 adders. So an unconditional loop will keep generating new 
> hardware, which wont fit in a any device. 
> 
> Suggesting an alternative way of implementing your function would be easier 
> if you posted the code you have now, but I think that a process with the 
> right sensitivity lis (and no loops) might be the soltion. (A process with 
> a sensitivity list will loop everytime one of the signals in the 
> sensitivity list changes)
> 
> Dines
> 
> 

I was going to do that at first, but didn't because as I
found in my reading, this should be a legal thing to do.

But... here's what I'm trying to do:

process is
begin
   loop
     wait until clk_2MHz = '0';
     start <= '0';
     wait until busy = '0';
     wait until bust = '1';
     data <= data_bus;
     start <= '1';
   end loop;
end process;

The idea is that, since the loop will take much
less than 500 nsec to run, I would wait until the
clock went low, trigger start, wait for busy to
go low, then high, then I could latch the data bus,
and clear start, then do it all over again.

Now, I'm just learning VHDL (I did well in the classes
and since I know Ada, the language per se isn't too hard),
so if there are ignorant mistakes in here, please
overlook them (and make suggestions if you wish).

BTW Quartus ALSO does not like having multiple wait
statements, which I also don't understand, because I've
seen examples in VHDL texts which indicate this should be
legal.

If anyone wishes, could you explain the divergence between
Quartus II and VHDL '93???  I've only been exposed to
one tool, so I really don't know what to expect (NOT like
a compiler...).

Regards,

TB


Article: 43156
Subject: Re: Altera/Quartus II: unconditional loop?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 14 May 2002 17:14:49 -0700
Links: << >>  << T >>  << A >>
Ted Bronson wrote:


> 
> But... here's what I'm trying to do:
> 
> process is
> begin
>   loop
>     wait until clk_2MHz = '0';
>     start <= '0';
>     wait until busy = '0';
>     wait until bust = '1';
>     data <= data_bus;
>     start <= '1';
>   end loop;
> end process;


You can do waits in a simulation testbench.
It's legal VHDL. However for synthesis
the only thing you can wait for is rising_edge(clk);


> Now, I'm just learning VHDL (I did well in the classes
> and since I know Ada, 


You're fortunate. VHDL is almost completely stolen from ADA.


> BTW Quartus ALSO does not like having multiple wait
> statements, which I also don't understand, because I've
> seen examples in VHDL texts which indicate this should be
> legal.


Textbooks cover the whole language.
Synth code is a subset.


> If anyone wishes, could you explain the divergence between
> Quartus II and VHDL '93???  I've only been exposed to
> one tool, so I really don't know what to expect (NOT like
> a compiler...).

Altera has given up trying to make MAX/Quartus cover
VHDL and instead supplies an OEM version of Leonardo for synthesis.

    -- Mike Treseler


Article: 43157
Subject: Re: Architecture for high-level reconfigurable computing
From: samg@codenet.net
Date: Wed, 15 May 2002 01:42:17 GMT
Links: << >>  << T >>  << A >>
On Tue, 14 May 2002 13:16:56 +0100, Rick Filipkiewicz
<rick@algor.co.uk> wrote:

>
>
>Nicholas Weaver wrote:
>
>> Virtex 2: Bitfiles can be encrypted with a 3DES key, and the 3DES key
>> is then loaded (through JTAG) into a distinct register on the part,
>> which has a separate power pin to maintain state.
>> --
>> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
>
>The problem comes when, for some reason, the battery fails and the user's
>board is now dead [User "No I really really didn't try to change the battery
>with the board powered down, honest"]. To avoid being faked the only real way
>to deal with this is to offer a free ``return-to-base'' service.
>
>There was a long thread on this subject some time ago discussing the battery
>endurance necessary to maintain the 3DES keys.
>
>Peter/Austin: Do you have any real life experience on the VBATT current drain
>now the V-2's have been characterised ? Any recommendations or apps notes on
>battery types &  circuits ?
>
>Is there, for example, any way of detecting the battery state from inside the
>chip to see if its dropped below 1V + some margin ? It might be worth a nA or
>2 to have this feature.
>
This was/is a real issue on Capcom based Arcade boards that would die
if the watch battery was removed. You had to send it back to their 
tech service area to replace the battery and reinstall the key.
I don't think it is all that bad of an idea in a final product but not
on a prototyping product. You are right that it is too easy to clear
the memory key.

Regards,
  Sam







Article: 43158
Subject: Re: Architecture for high-level reconfigurable computing
From: samg@codenet.net
Date: Wed, 15 May 2002 01:44:28 GMT
Links: << >>  << T >>  << A >>
On Tue, 14 May 2002 19:47:22 GMT, "Steve Casselman"
<sc.nospam@vcc.com> wrote:

>As FPGAs get more popular people will just get together and figure out the
>bitstream anyway. So why not just publish the whole thing and get it over
>with? All your doing is making people jump through hoops. With the little
>information already published people are already making tools. Imagine if
>Intel had you encrypt all your programs because some people were afraid of
>having their programs decompiled? The software world would be in the stone
>age. And that is where we are as far as programming FPGAs. Maybe someone at
>GNU will start hacking away. I don't think it would take much.
>
>Steve
>
>
>"Peter Alfke" <Peter.Alfke@xilinx.com> wrote in message
>news:3CE03B81.B6624D70@xilinx.com...
>
>
>> 1.
>> It might make some users feel vulnerable that their design can be
>> reverse-engineered and then slightly modified to hide the rip-off.
>>
>> 2.
>> It might expose Xilinx to unreasonable and unsupportable user questions,
>> especially when they painted themselves into a corner. And he who sells
>the
>> chips ultimately is stuck with the cry for help...
>>
>> Peter Alfke
>>
>
>
Check out the Icarus project. (www.icarus.com)
Stephen Williams has work to create a Verilog simulator with
a FPGA synthesis tool built into it. The code is GPL, it might
be an interesting place to start.

Sam

Article: 43159
Subject: Re: Architecture for high-level reconfigurable computing
From: Keith R. Williams <krw@attglobal.net>
Date: Tue, 14 May 2002 22:13:07 -0400
Links: << >>  << T >>  << A >>
In article <abrrhh$2igr$1@agate.berkeley.edu>, 
nweaver@CSUA.Berkeley.EDU says...
> In article <MPG.174b1a664828c90198979e@enews.newsguy.com>,
> Keith R. Williams  <krw@btv.ibm.com> wrote:
> 
> >> 2. are not good for keeping a secret ( easily detected )
> >
> >It's done for cryptographically strong data (e.g. private keys) in FIPS 
> >140-1 level-4 crypto equipment. Secrets are a pretty big deal in this 
> >application.
> 
> Then again, look at the massive physical packaging to maintain that
> level of security in the IBM 4758 (Is this what you are referring
> to?).

No, I was referring to the current (though I've been out of the 
business for almost ten years) mainframe integrated crypto stuff.  
The secure wall is done on chip for these things.

Understand that I did the physical security, master key storage, 
and user interface on the original mainframe (ES3090, then 
ES9000) crypto hardware.  Yes, this stuff was massively 
expensive.  The later fuse/asymmetric key stuff nearly as bad. 
Depending on the security requirements it can be rather simple to 
do, or expensive. 

> Also, I thought that they used SRAM, simply because it is much easier
> to zero out the contents when the physical tamper-sensor is disturbed,
> keeping the SRAM bits from being burned in by the use of occasional
> data moves.

Well...  I proposed my solution (six copies of the master keys, 
constantly scrubbed and flipped) to the 4758 folks...  ;-)  They 
insisted on a radiation detector.  The "sensor" wasn't specified 
for the purpose and I didn't want to *ever* tell our customer 
that they'd been nuked unless the system was glowing. 

Engineers differ and customers differ. The intended user of my UI 
was a major bank VP.  "You're dead" wasn't something I wanted to 
tell them.  ...particularly when I had no way of testing the 
"you're dead" sensor.

> I wonder what sort of ram-keeper/ram-saver is used in the Virtex II
> mechanism?

I don't think cryptographic security is a design point for 
Xilinx.  An FPGA with crypto-clearance!  What a concept!  ;-)

My point is that such things *are* possible.  The level of 
security I've seen requested on this NG is well within the 
possible.  The question, as Peter has asked, is how interested 
*are* people in bitstream security?  I'm betting, as Xilinx has, 
not very. 

OTOH, I agree with the other side, batteries to hold config keys 
are a *bad* idea. The customer problems are likely to outstrip 
any benefit.  That decision is up to the developer and the PHBs.  
I know I wouldn't be happy doing it.

----
  Keith

Article: 43160
Subject: Re: Frequency synthesiser
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 15 May 2002 05:11:31 -0000
Links: << >>  << T >>  << A >>
This discussion brings up a question I've been wondering about...

Suppose I have an FPGA, DAC, VCO or VXCO, and a good reference clock,
and the FPGA is connected to a PC, say by PCI.

If I'm trying to build a frequency synthesiser, can I move some of
the PLL into software?

I'm thinking of a DDS to toggle between X and X+1 going into the DAC.
The FPGA has a pair of counters one from the reference clock and one
from the VXCO output.  Reading one latches the other so the software
can get see both as of the same time.  From that the software can
adjust the DDS parameters.  This may not be a real DDS, but I think
it's the same math.

Is it reasonable to put a low-enough low pass filter on the
DAC output so that the output of the VCO/VXCO will be a clean
signal rather than wobbling all over tracking the bumps in the DDS?

I'm expecting the DDS output to be something like 3 cycles high, 2 low,
3 high, 2 low, 2 high, 2 low...  That is steal a cycle from some simple
pattern occasionally.  [That's probably a bad example.  I think you
can do better than a 3/2 type basic pattern.  Either the high or low should
be only 1 cycle to put out a higher frequency that will be easier to
filter.]

Is there a good book, article, or web page that covers this?

Actually, I think the "software" for this could go into the FPGA
too, but it might be easier to think/debug if I called it software.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 43161
Subject: Re: Frequency synthesiser
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 15 May 2002 19:04:38 +1200
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> This discussion brings up a question I've been wondering about...
> 
> Suppose I have an FPGA, DAC, VCO or VXCO, and a good reference clock,
> and the FPGA is connected to a PC, say by PCI.
> 
> If I'm trying to build a frequency synthesiser, can I move some of
> the PLL into software?
> 
> I'm thinking of a DDS to toggle between X and X+1 going into the DAC.
> The FPGA has a pair of counters one from the reference clock and one
> from the VXCO output.  Reading one latches the other so the software
> can get see both as of the same time.  From that the software can
> adjust the DDS parameters.  This may not be a real DDS, but I think
> it's the same math.
> 
> Is it reasonable to put a low-enough low pass filter on the
> DAC output so that the output of the VCO/VXCO will be a clean
> signal rather than wobbling all over tracking the bumps in the DDS?
> 
> I'm expecting the DDS output to be something like 3 cycles high, 2 low,
> 3 high, 2 low, 2 high, 2 low...  That is steal a cycle from some simple
> pattern occasionally.  [That's probably a bad example.  I think you
> can do better than a 3/2 type basic pattern.  Either the high or low should
> be only 1 cycle to put out a higher frequency that will be easier to
> filter.]
> 
> Is there a good book, article, or web page that covers this?

Search for Fractional-N Synthesizers, and maybe Rate Multipliers, which
make good filter-able DACs, so are suited to your 'dithering' scheme.

-jg

Article: 43162
Subject: Life Support (was Re: Architecture for high-level reconfigurable computing)
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 15 May 2002 00:11:29 -0700
Links: << >>  << T >>  << A >>
Peter Alfke <Peter.Alfke@xilinx.com> writes:
> That's the beauty of FPGAs; users can do anything they please, without
> telling us about it ( life support equipment being explicitly
> excluded, see one of the first pages of our data book).

That brings up something I've been wondering for a while.  If you're
designing life support equipment and you need some components, what do
you do?  Since all the semiconductor vendors have these policies, it
would seem that you have to ignore the policies and use the components
anyhow.

I assume that the semiconductor vendor is counting on their publicly
stated policy to shield them from liability if their part in the life
support equipment fails.  In practice, does that work?

Suppose a component fails, but expert witnesses testify that the
equipment was designed properly, e.g., there was no reason to believe
that the component was not actually suited for use in the life support
equipment despite the disclaimer of the component manufacturer.  In such
a case, is a court likely to find the equipment vendor to have more
liability on the basis of the disclaimer than they might otherwise have
had?

Article: 43163
Subject: Re: Announce:GPLed 6502 IP core
From: Micah Dowty <micahjd@users.sourceforge.net>
Date: Wed, 15 May 2002 09:00:21 GMT
Links: << >>  << T >>  << A >>
This is the first time I've heard of the SFL language. It looks
interesting, but I managed to find only sparse documentation on it. Is
there any good documentation? More important, what license is it released
under and where can I get the source?

On Sun, 12 May 2002 16:52:16 -0600, Naohiko Shimizu wrote:

> Hi, I made 6502 IP core to use in my class, and I would like to release
> this core with GPL license.
> 
> See and enjoy with it.
> 
> http://shimizu-lab.dt.u-tokai.ac.jp/pgm/m65/index.html
> 
> Naohiko Shimizu
> 
> ------------------------------------------------------
>     m65 - 6502 instruction compatible micro processor
> 
>     Copyright (C) 2002-
>     Naohiko Shimizu <nshimizu@keyaki.cc.u-tokai.ac.jp>
> 
>     m65 is provided as a synthesizable soft IP core under GPL. The
>     description language is SFL and can be synthesized for any FPGA such
>     as ALTERA or Xilinx. When synthesized for ALTERA FLEX10K series, it
>     will fit within 600 logic cells. I successfully complied for a FLEX
>     EPF10K10LC84-3. When compiled for a gate array, it will use under
>     4000 gates.
> 
>     If you want to try the core, you sould download PARTHENON tools from
>     NTT WEB page. (It is free for non-commercial use)
> 
>       http://www.kecl.ntt.co.jp/parthenon/
> 
>     Because this IP core is covered with GPL2, if you make any products
>     with this IP core, you should provide your source code and/or
>     schematics for the users, freely. See the COPYING file for more
>     details.
> 
>     Anyone who wants other license, or VHDL version, please contact me:
> 
>      Associate Prof. Naohiko Shimizu
>      Dept. Communications Engineering,
>      School of Information Technology and Electronics, Tokai University
>      1117 Kitakaname, Hiratsuka-city, 259-1292 Japan Emal:
>      nshimizu@keyaki.cc.u-tokai.ac.jp URL:
>      http://shimizu-lab.dt.u-tokai.ac.jp/ TEL: +81-463-58-1211(ext.4084)
>      FAX: +81-463-58-8320
>     
>     The documents:
> 
>       README.TXT: This file
>       COPYING   : License document (GPL2)
> 
>     The logic is consisted with:
> 
>       inc16.sfl : 16bit PC incrementer
>       alu65.sfl : ALU logic
>       data65.sfl: Datapath logic of MPU
>       m65.sfl   : Control logic of MPU
>       m6502.sfl : 6502 compatible soft IP core m6505.sfl : 6505
>       compatible soft IP core m6502chip.sfl : Bidirectional databus
>       version
> 
>     Simulation environment is provided with Lee Davison's EhBASIC After
>     you installed PARTHENON, you can run the simulator "seconds" and
>     input "basic.run" as a command. After 45000 cycles simulation, the
>     script will dump the Lee's BASIC output strings in hex format.
> 
>       basic.sfl   : Simulation main logic
>       basic.run   : Simulation main script
>       instring.dat: BASIC command inputs script o64tohex    : o64 to hex
>       conversion script od2hex.awk  : od dump to hex file conversion
> 
>     *)monitor.rom : BIOS, interrupt vectors based on Lee's monitor
>     *)basic.rom   : Lee Davison's EhBASIC ROM image
> 
> *) These two files are not covered with GPL,
>    see the license on the Lee's page:
> 
>    http://members.lycos.co.uk/leeedavison/index.html
> 
>    And for his EhBASIC,
> 
>    http://members.lycos.co.uk/leeedavison/6502/ehbasic/index.html
> 
> 
>     Synthesized demo code:
>     The demo m6505's address space is restricted for 10bit, though it
>     has 12bit address lines. (The SFL source code have 16/12 bit
>     addressing capability.)
> 
>       m6505/m6505.tdf : Converted TDF from the synthesized EDIF file
>       m6505/m6505.sym : Symbol file for m6505 m6505/m6505chip.gdf :
>       Demonstration for make a real chip.
> 
>     This code is free software IP; 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 2 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, write to the Free Software
>     Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

Article: 43164
Subject: Re: Please help me figure out serial prom problem
From: Utku Ozcan <utku.ozcan@netas.com.tr>
Date: Wed, 15 May 2002 12:08:51 +0300
Links: << >>  << T >>  << A >>
Hi,

the last FPGA in the PROM chain must have DriveDONE parameter of "YES".
(reference: Spartan-II Config and Readback", page 10, 2nd undivided paragraph,
XAPP176, v0.9, 4.12.1999)

My application is a daisy chain of 2 Spartan-II XC2S50-5FG256Cs.

Please read the corresponding documents very carefully.

Utku

"C.W. THomas" wrote:

> HI;
>
> Thanks for reading this.  I have been trying to program a sartan II chain.
>


Article: 43165
Subject: Processor interface to memory mapped FPGA
From: nagaraj@accord-soft.com (Nagaraj)
Date: 15 May 2002 03:31:31 -0700
Links: << >>  << T >>  << A >>
Dear all,
 I am using Xilinx Webpack and ModelSimXE Starter edition for
implementing Processor interface to a memory mapped FPGA (in VHDL).
Interface signals are ADDRESS,DATA,CSBAR,READBAR and WRITEBAR.
 The problem is regarding FPGA part of the VHDL code. The port DATA is
declared as INOUT port. In the code, the DATA bus is tristated when
CSBAR signal is '1'.
Read alone(WRBAR always '1') and write alone(RDBAR always '1') works
fine. For testing both read and write in one simulation go, I have to
give a value to DATA bus(for WRITE). In the testbench if I write
anything to DATA bus once or twice, it is assuming that I am using
DATA bus for the entire simulation. Hence when I try to do a READ
operation, there are two drivers for the DATA bus. One is the
testbench value and other is what I have got by READ operation. So the
simulator is showing worng result (like "X0X000XXX  ...").
 My question is where is the problem? Is it in the code(i am 100%
against this) or in the testbench or in the simulator?
 Some observations : 
  If I run the simulation manually, that is by providing values for
signals through "Force" command, it just works fine. The procedure
followed is this. Before a WRITE operation I do a "force" onto the
DATA bus with some value, make the WRITE signal low, assert the WRITE
signal after some duration and finally do a "no force" command on the
DATA bus. But this I can not do for entire simulation duration as it
takes hours together.

Could anyone of you please provide me answer for the above problem?
Has anybody done or come-across litrature/vhdl module for processor
interface to memory mapped FPGA ( FPGA part of the code).

Thanx in advance,
Nagaraj

Article: 43166
Subject: Re: Processor interface to memory mapped FPGA
From: Laurent Gauch <laurent.gauch@amontec.com>
Date: Wed, 15 May 2002 16:21:47 +0200
Links: << >>  << T >>  << A >>
Nagaraj,

In you testbench, when you are reading a data comming from you DATA bus, 
you have to fix your bus with (others => 'Z'). If you don't fix with 
tristate value, you will see 'X' value when the signal is driven by two 
different value(ex: the up fix an '1' and the memory fix a '0').
Same way for your memory design.

See the following example:

-- VHDL tristate buffer for your memory and microprocessor:
--
--             +--------------< Doe
--             ¦
--             ¦
--             ¦/¦
-- ---     D   / ¦
--¦PAD¦ <>-+--/  ¦------------< Dout
-- ---     ¦  \  ¦
--         ¦   \ ¦
--         ¦    \¦
--         ¦
--         +------------------> Din

--***************************************

D <= Dout WHEN Doe = '1' ELSE (OTHER => 'Z');
Din <= D ;

-- for the up
Doe <= '1' WHEN Write= '1' ELSE '0' ;
-- for the memory
Doe <= '1' WHEN Read= '1' ELSE '0' ;
-- I didn't include chip select or other control signals

--***************************************

This works well.
I hope this help you.

Laurent Gauch
www.amontec.com
_____________________________________________
Introducing to new PCI boards for prototyping
With Virtex-II pro mezzanine and Spartan-II
Free drivers and firmware softwares



Nagaraj wrote:

> Dear all,
>  I am using Xilinx Webpack and ModelSimXE Starter edition for
> implementing Processor interface to a memory mapped FPGA (in VHDL).
> Interface signals are ADDRESS,DATA,CSBAR,READBAR and WRITEBAR.
>  The problem is regarding FPGA part of the VHDL code. The port DATA is
> declared as INOUT port. In the code, the DATA bus is tristated when
> CSBAR signal is '1'.
> Read alone(WRBAR always '1') and write alone(RDBAR always '1') works
> fine. For testing both read and write in one simulation go, I have to
> give a value to DATA bus(for WRITE). In the testbench if I write
> anything to DATA bus once or twice, it is assuming that I am using
> DATA bus for the entire simulation. Hence when I try to do a READ
> operation, there are two drivers for the DATA bus. One is the
> testbench value and other is what I have got by READ operation. So the
> simulator is showing worng result (like "X0X000XXX  ...").
>  My question is where is the problem? Is it in the code(i am 100%
> against this) or in the testbench or in the simulator?
>  Some observations : 
>   If I run the simulation manually, that is by providing values for
> signals through "Force" command, it just works fine. The procedure
> followed is this. Before a WRITE operation I do a "force" onto the
> DATA bus with some value, make the WRITE signal low, assert the WRITE
> signal after some duration and finally do a "no force" command on the
> DATA bus. But this I can not do for entire simulation duration as it
> takes hours together.
> 
> Could anyone of you please provide me answer for the above problem?
> Has anybody done or come-across litrature/vhdl module for processor
> interface to memory mapped FPGA ( FPGA part of the code).
> 
> Thanx in advance,
> Nagaraj
> 


Article: 43167
Subject: Re: Architecture for high-level reconfigurable computing
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 15 May 2002 08:03:24 -0700
Links: << >>  << T >>  << A >>
Jim,

I didn't say that, but you guessed it.

In all fairness, as the we descend into the UDSM world, all foundries
have NVRAM/ROM (read: fuse) type cells that they are offering (eg in
0.1u).  This is good, as if you use them, they will support them.  Their
programming voltages, retention, etc. is all characterized, and the
cells to store, readback, and write, are all IP that the foundry will
support if you use it exactly as they propose.

As with all IP, one pays for it if it is worth anything.  That isn't the
issue here, as having even 1K bits of NVRAM/ROM would be useful in an
FPGA, so as a percentage of the die, it is almost invisible.

We are just working with our foundries to engage when we see that the
technology will support what we need to accomplish.

It is still scarey, as at 0.1u the reason why these cells work, is that
they are so easy to blow up (ie make a 0, instead of a 1).

Obviously, we are not into fuse (or anti-fuses), and have a long
tradition of SRAM based FPGAs and EEPROM, EPROM based CPLDs.  Fuses just
make us nervous ..... did they blow?  did we blow something else? Will
they heal?  etc.  Right now, if a foundry is asked what the reliability
of their 0.1u NV technology is, you can't expect an answer .... no one
has built enough of anything yet to run a reliability study on.

Austin



Jim Granville wrote:

> Austin Lesea wrote:
> >
> > Jim,
> >
> > Yup.  Been there, done that.  No news.  Nothing there.
>
>  You mean it has more 'qualifications' and 'vaporware nature'
> than suggested by their marketing info :)
>
> -jg


Article: 43168
Subject: Re: Architecture for high-level reconfigurable computing
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 15 May 2002 08:12:17 -0700
Links: << >>  << T >>  << A >>
Sam,

Battery backup is an old, old technology.

You get one of those "supercaps" that is ~ 1F.  You also get a 150 mAHr coin
cell.  You connect the Vbatt pin to the supercap through a 100K ohm resistor.  You
connect the supercap to the battery through another 100K ohm resistor.  If you
pull the battery, it takes a long long time to lose the key (and that only happens
if the power is off, as well).

If the battery dies (i.e. you bought the wrong battery, as a lithium cell lasts
twenty years -- I have replaced my camera's lithium cell once in the last 29
years), then when power is removed, the key goes away after the supercap has
discharged.

The current drain is 0.1 nA, max (was not tested on early ES, so some parts were
leaky, and the batteries could and did get exhausted, but we fixed that in the
test program).  I=CdV/dt, or dt= C  dV/I, and C = 1, V = 2V (assume 3 V discharges
to 1V), and I = 1E-10, so dt = 3E10 seconds.  Now the supercap can't be that good,
so it is whatever the self discharge rate is of the supercap.  Could be weeks.

Austin

samg@codenet.net wrote:

> On Tue, 14 May 2002 13:16:56 +0100, Rick Filipkiewicz
> <rick@algor.co.uk> wrote:
>
> >
> >
> >Nicholas Weaver wrote:
> >
> >> Virtex 2: Bitfiles can be encrypted with a 3DES key, and the 3DES key
> >> is then loaded (through JTAG) into a distinct register on the part,
> >> which has a separate power pin to maintain state.
> >> --
> >> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
> >
> >The problem comes when, for some reason, the battery fails and the user's
> >board is now dead [User "No I really really didn't try to change the battery
> >with the board powered down, honest"]. To avoid being faked the only real way
> >to deal with this is to offer a free ``return-to-base'' service.
> >
> >There was a long thread on this subject some time ago discussing the battery
> >endurance necessary to maintain the 3DES keys.
> >
> >Peter/Austin: Do you have any real life experience on the VBATT current drain
> >now the V-2's have been characterised ? Any recommendations or apps notes on
> >battery types &  circuits ?
> >
> >Is there, for example, any way of detecting the battery state from inside the
> >chip to see if its dropped below 1V + some margin ? It might be worth a nA or
> >2 to have this feature.
> >
> This was/is a real issue on Capcom based Arcade boards that would die
> if the watch battery was removed. You had to send it back to their
> tech service area to replace the battery and reinstall the key.
> I don't think it is all that bad of an idea in a final product but not
> on a prototyping product. You are right that it is too easy to clear
> the memory key.
>
> Regards,
>   Sam


Article: 43169
Subject: Re: Frequency synthesiser
From: John_H <johnhandwork@mail.com>
Date: Wed, 15 May 2002 15:34:25 GMT
Links: << >>  << T >>  << A >>
Are you wanting to modulate the DDS and you're unhappy with the current
implementation?  A DDS is designed to provide sinusoidal values to the DAC.  The
DAC is lowpassed to obtain a clean sine with exquisite time resolution.  What are
you trying to do with your dithering?

Jim's mention of Fractional-N synthesis might be what you're working towards -
it's a very pretty VCO solution for many applications - but the dithering doesn't
bother with a DAC since the Fractional-N deals with the dividers feeding the
phase comparator in a PLL.  The two counters you speak of might be an attempt at
this phase comparison, but I'm lost as to how the DDS would fit into the
situation.

DDS devices usually have very high frequency resolution (sub hertz) and outputs
that can drive 8 to 16 bit DACs for precision sinusoidal generation.

Is the DAC intended as the voltage control on the VCXO?  I wouldn't expect pretty
results from a DAC feeding a VCO, but I'm open to the possibility.  The
sensitivity is just so high.  If this is your approach, the "DDS" would just be a
phase accumulator - no sinusoidal lookup needed - and the software would need to
adjust the DAC parameters since you'd be "calculating" the phase error and making
the appropriate adjustment to the VCXO.

Fractional-N synthesizers can be almost arbitrarily precise and agile at the same
time.  Standard PLL designs is usually a choice of either one or the other.  I'll
see if I can find my book on digital frequency synthesis for a reference though I
don't know if fractional-N is covered.



Hal Murray wrote:

> This discussion brings up a question I've been wondering about...
>
> Suppose I have an FPGA, DAC, VCO or VXCO, and a good reference clock,
> and the FPGA is connected to a PC, say by PCI.
>
> If I'm trying to build a frequency synthesiser, can I move some of
> the PLL into software?
>
> I'm thinking of a DDS to toggle between X and X+1 going into the DAC.
> The FPGA has a pair of counters one from the reference clock and one
> from the VXCO output.  Reading one latches the other so the software
> can get see both as of the same time.  From that the software can
> adjust the DDS parameters.  This may not be a real DDS, but I think
> it's the same math.
>
> Is it reasonable to put a low-enough low pass filter on the
> DAC output so that the output of the VCO/VXCO will be a clean
> signal rather than wobbling all over tracking the bumps in the DDS?
>
> I'm expecting the DDS output to be something like 3 cycles high, 2 low,
> 3 high, 2 low, 2 high, 2 low...  That is steal a cycle from some simple
> pattern occasionally.  [That's probably a bad example.  I think you
> can do better than a 3/2 type basic pattern.  Either the high or low should
> be only 1 cycle to put out a higher frequency that will be easier to
> filter.]
>
> Is there a good book, article, or web page that covers this?
>
> Actually, I think the "software" for this could go into the FPGA
> too, but it might be easier to think/debug if I called it software.
>
> --
> The suespammers.org mail server is located in California.  So are all my
> other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
> commercial e-mail to my suespammers.org address or any of my other addresses.
> These are my opinions, not necessarily my employer's.  I hate spam.


Article: 43170
Subject: Re: Altera/Quartus II: unconditional loop?
From: "Kevin Neilson" <kevin-neilson@removethistextattbi.com>
Date: Wed, 15 May 2002 15:58:27 GMT
Links: << >>  << T >>  << A >>
This is inline sequential code, e.g. software.  This may run as a simulation
but will not create hardware.  Since you are still learning (synthesizable)
HDL, I suggest you draw a schematic of the circuit you want to create and
then convert it to HDL.  If you can't visualize the circuit, then the
synthesizer probably can't either.
-Kevin

"Ted Bronson" <tedbronson@hotmail.com> wrote in message
news:3CE1A04B.8000506@hotmail.com...
>
>
> Dines Justesen wrote:
>
> >>I'm a bit new to all this... why doesn't the Quartus II
> >>support the "loop <body> end loop;" loop??
> >>
> >
> > When synthesizing VHDL loops inside a process will result in the logic
> > inside the loop being repeated as many time as the code is looped. So if
> > you loop a statement which generates and adder 16 times, it will
generally
> > create 16 adders. So an unconditional loop will keep generating new
> > hardware, which wont fit in a any device.
> >
> > Suggesting an alternative way of implementing your function would be
easier
> > if you posted the code you have now, but I think that a process with the
> > right sensitivity lis (and no loops) might be the soltion. (A process
with
> > a sensitivity list will loop everytime one of the signals in the
> > sensitivity list changes)
> >
> > Dines
> >
> >
>
> I was going to do that at first, but didn't because as I
> found in my reading, this should be a legal thing to do.
>
> But... here's what I'm trying to do:
>
> process is
> begin
>    loop
>      wait until clk_2MHz = '0';
>      start <= '0';
>      wait until busy = '0';
>      wait until bust = '1';
>      data <= data_bus;
>      start <= '1';
>    end loop;
> end process;
>
> The idea is that, since the loop will take much
> less than 500 nsec to run, I would wait until the
> clock went low, trigger start, wait for busy to
> go low, then high, then I could latch the data bus,
> and clear start, then do it all over again.
>
> Now, I'm just learning VHDL (I did well in the classes
> and since I know Ada, the language per se isn't too hard),
> so if there are ignorant mistakes in here, please
> overlook them (and make suggestions if you wish).
>
> BTW Quartus ALSO does not like having multiple wait
> statements, which I also don't understand, because I've
> seen examples in VHDL texts which indicate this should be
> legal.
>
> If anyone wishes, could you explain the divergence between
> Quartus II and VHDL '93???  I've only been exposed to
> one tool, so I really don't know what to expect (NOT like
> a compiler...).
>
> Regards,
>
> TB
>



Article: 43171
Subject: Re: Architecture for high-level reconfigurable computing
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 15 May 2002 17:36:01 +0100
Links: << >>  << T >>  << A >>


Austin Lesea wrote:

> The current drain is 0.1 nA, max (was not tested on early ES ... <snip>

The Jan 2002 V-2 data sheet shows IBATT (max) = 100nA ?


Article: 43172
Subject: PCI Board Project
From: weirdo@bbs.frc.utn.edu.ar (Mauricio Lange)
Date: 15 May 2002 10:32:25 -0700
Links: << >>  << T >>  << A >>
Hello, 
I need to design a PCI32 add-in board as a school project. Having a
XESS XS40v1.2 eval board, I have some experience with the XC4010XL.
The question goes as this: Is it feasible to implement a minimum
target configuration with this IC? If that were not the case, to which
FPGA (in the XC4000 line) should I jump? And, finally (yes, I am a
newbie in the area): where can I get prices of XC4000 ICs? I did a
search and Insight Electronics has the parts, but a XC4010XL-09 PC84
costs $70 or more (I have no access to their web page now, my browser
doesn't support I-dont-know-what, and get a message prompting me to
download IE and/or NN). Higher densities FPGAs (say 4013, 4020) costs
much more.
Are this the usual prices in the market?

Thank you very much

Mauricio Lange
mlange@ieee.org

Article: 43173
Subject: Re: PCI Board Project
From: Micah Dowty <micahjd@users.sourceforge.net>
Date: Wed, 15 May 2002 18:06:35 GMT
Links: << >>  << T >>  << A >>
At those prices you're probably better off using a Spartan II device. You
can use the WebPack tools to design for them. I've seen the Spartan II
for $20 or so at digi-key but only in quantities of at least 25 IIRC. I
might need to get me some FPGAs for my own board in the sort-of-near
future. Is there any place to get them in < 10 quantity nowadays?

On Wed, 15 May 2002 11:32:25 -0600, Mauricio Lange wrote:

> Hello,
> I need to design a PCI32 add-in board as a school project. Having a XESS
> XS40v1.2 eval board, I have some experience with the XC4010XL. The
> question goes as this: Is it feasible to implement a minimum target
> configuration with this IC? If that were not the case, to which FPGA (in
> the XC4000 line) should I jump? And, finally (yes, I am a newbie in the
> area): where can I get prices of XC4000 ICs? I did a search and Insight
> Electronics has the parts, but a XC4010XL-09 PC84 costs $70 or more (I
> have no access to their web page now, my browser doesn't support
> I-dont-know-what, and get a message prompting me to download IE and/or
> NN). Higher densities FPGAs (say 4013, 4020) costs much more. Are this
> the usual prices in the market?
> 
> Thank you very much
> 
> Mauricio Lange
> mlange@ieee.org

Article: 43174
Subject: Re: Architecture for high-level reconfigurable computing
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 15 May 2002 11:44:07 -0700
Links: << >>  << T >>  << A >>
Rick,

I'll see why the datasheet has this number....

Austin

Rick Filipkiewicz wrote:

> Austin Lesea wrote:
>
> > The current drain is 0.1 nA, max (was not tested on early ES ... <snip>
>
> The Jan 2002 V-2 data sheet shows IBATT (max) = 100nA ?




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
2019JanFebMar2019

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