Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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
Does anybody know what type of cooling is available for a XC2V3000-4BF957? Any good or bad experiences? Thanks in advance BillArticle: 43152
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, > BertArticle: 43153
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! > > MarcArticle: 43154
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 :) -jgArticle: 43155
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
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: 43157On 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, SamArticle: 43158
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. SamArticle: 43159
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. ---- KeithArticle: 43160
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
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. -jgArticle: 43162
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
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
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
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, NagarajArticle: 43166
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
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 :) > > -jgArticle: 43168
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, > SamArticle: 43169
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
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
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
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.orgArticle: 43173
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.orgArticle: 43174
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:
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