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
Tim 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. > > All together, for the umpteenth time: > "Please can we have these few register bits as flash" Not until FLASH can be placed in the corner of a CMOS process, without needing the rules/mask sets across the whole die. That said, there are companies claiming to have NV RAM processes, supposedly CMOS FAB compatible - these are small size memories, but certainly OK for Keys / IDs / etc, Then there's also MRAM... -jgArticle: 43101
Hi all, anybody out here knows a CPLD/FPGA which can sink at least 50 mA on a 5V TTL compatible output ? cheers & thanksArticle: 43102
Clamping diode?
Rick Filipkiewicz wrote:
> Peter Alfke wrote:
>
> >
> >
> > These circuits do not mysteriously work or don't work. ...
>
> ... unless they're being eaten by the great metastability beast. Maybe the
> work/!work is related to seasonal variation in lab temperature :-).
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 43103
Tim wrote:
>
> All together, for the umpteenth time:
> "Please can we have these few register bits as flash"
Same answer for the umpteenth time:
"No, as long as that would mean sacrificing the standard,
high-volume and high-performance CMOS logic/microprocessor process". Tell
us how it can be done without significant impact on fab availability,
performance, and cost, and we will really listen. We are convinced these
conditions cannot be met today. Hope is eternal!
Peter Alfke
Article: 43104
In article <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk>,
Tim <tim@rockylogic.com.nooospam.com> wrote:
>All together, for the umpteenth time:
> "Please can we have these few register bits as flash"
All together, for the umpteenth time:
"Flash slows the process down, and anyway, damnit, being properly
paranoid, I prefer battery backed SRAM, its harder to probe."
--
Nicholas C. Weaver nweaver@cs.berkeley.edu
Article: 43105Rick Filipkiewicz wrote: > > ... unless they're being eaten by the great metastability beast. Maybe the > work/!work is related to seasonal variation in lab temperature :-). Sure, but then I am looking for: "Works mostly, but not al low Vcc or at hot, or at cold, or..." Or: "works in some devices, but not in all..." Or" works only when I put 100 pF across the clock line..." "Does not work" is like going to the doctor and saying "I am sick". Complete lack of information... Peter AlfkeArticle: 43106
Steve Casselman wrote:
> > > A key weakness of C, is the sequential nature of all descriptions,
>
> This is not really correct. C has lots of parallelism. It always amazes me
> when people say there is no parallelism. Here is a line of very parallel C
> code.
>
> a = b+c, d= e+f, Myfunc();
>
> According to the C specs the above line can be executed in parallel. The
> problem is if you can get different answers since the specs don't say what
> order they must executed in if you do them one at a time.
> example
>
> a = b , b = a ;
>
> Could be "a" and "b" have the value of "a" or they have the value of "b" or
> "a" and "b" swap values. It's one of the reasons Java only has lists for
> initializations.
Useful parallelism would need to define what happens. Perhaps it would
be better to state that C has no useful parallelism. Suppose I wanted
to swap a and b in parallel, how could I do this in C? I can in other
parallel languages.
For example, in HandelC:
par
{
a = b;
b = a;
}
"a" and "b" will swap values.
Or in VHDL:
process (clk) begin
if rising_edge(clk) then
a <= b;
b <= a;
end if;
end process;
"a" and "b" will again swap values.
--
Phil Hays
Article: 43107Phil Hays <SpamPostmaster@attbi.com> wrote: > Or in VHDL: > > process (clk) begin > if rising_edge(clk) then > a <= b; > b <= a; > end if; > end process; > > "a" and "b" will again swap values. > Correct me if i'm wrong, but aren't processes in VHDL sequential? if you did this outside of a process, then they will swap values...but inside a process, you just made both a and b have the value of b. --buddyArticle: 43108
There's a big difference between having the programmer specify the parallelism, vs. hoping someday someone will figure out algorithms so that a compiler that can find it. Many man-years have been spent trying to make compilers that can find the inherent parallelism in a program, and so far only some loop-level parallelism can be exploited. Adding features to a language like fork and join with explicitly stated synchronization will get you to useful parallelism far sooner than waiting for the compiler that does it automatically. -Stan "Steve Casselman" <sc.nospam@vcc.com> wrote in message news:dAWD8.870$q67.72741089@newssvr14.news.prodigy.com... > > > A key weakness of C, is the sequential nature of all descriptions, > > > This is not really correct. C has lots of parallelism. It always amazes me > when people say there is no parallelism. Here is a line of very parallel C > code. > > a = b+c, d= e+f, Myfunc(); > > According to the C specs the above line can be executed in parallel. The > problem is if you can get different answers since the specs don't say what > order they must executed in if you do them one at a time. > example > > a = b , b = a ; > > Could be "a" and "b" have the value of "a" or they have the value of "b" or > "a" and "b" swap values. It's one of the reasons Java only has lists for > initializations. > > If you write a compiler you'll see what I mean. > > Steve > >Article: 43109
"Phil Connor" <philip_john_connor@hotmail.com> writes: > "Petter Gustad" <newsmailcomp1@gustad.com> wrote in message > news:m3u1pjrl1t.fsf@scimul.dolphinics.no > > > > For volumes like that I would go for an ASIC using a PCI core where > > you can get the HDL source (Synopsys, RaviCAD etc.). You can of course > > make a FPGA prototype using the same core which will let you test your > > design with all the various host bridges available. > > > > Petter > > > Hi Petter, > > Would you have any links for info on the host bridges or other test > techniques? Most likely you will have to sign lots of NDA's (ServerWorks etc.) in order to get information on the various host bridges. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 43110
Hi! >> process (clk) begin >> if rising_edge(clk) then >> a <= b; >> b <= a; >> end if; >> end process; >> >> "a" and "b" will again swap values. >> >> > Correct me if i'm wrong, but aren't processes in VHDL sequential? > > if you did this outside of a process, then they will swap values...but > inside a process, you just made both a and b have the value of b. I'm a VHDL newbee, so I have problems understanding the statement "processes are sequential" too. We were told that, but when thinking of the synthesized process, I can't imagine, that the FPGA then "executes" the statements after each other, waiting until the previous has finished and then continuing with the next. But, one thing we were told too is, that in processes, all _signals_ are updated _at the end_. So, you can assign as many values as you want, only the last value will be assigned to the signal at the "end process" line. And: the signal will hold it's initial value in the hole process, i.e. "a" in the above example will hold the value it had when "entereing" the process in the "b <= a;" statement. Think of a D-Flipflop. It holds the initial value during the hole process, and only when clk rises, it feeds through its input value to the output. Variables behave different, they will get the value immediately. So, the above example (which uses signals because of the "<=" assignment) really swaps a and b. If it would be written with variables (assignment with ":=") a and b will have the value of b afterwards. Now my question: How true is the statement "processes are sequential" with regard to synthesis. E.g. if there are several "if" statements after each other (not nested!), a "case" statement, ... aren't they synthesized parallel? How are variables synthesized inside a process? Will they get a register (D-FF) like signals within a "if rising_edge(clk) then" clause? Thanks HansiArticle: 43111
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: 43112Nicholas 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.Article: 43113
In article <3CE0874C.C18C852@earthlink.net>, palfke@earthlink.net says... > > > Tim wrote: > > > > > All together, for the umpteenth time: > > "Please can we have these few register bits as flash" > > Same answer for the umpteenth time: > "No, as long as that would mean sacrificing the standard, > high-volume and high-performance CMOS logic/microprocessor process". Tell > us how it can be done without significant impact on fab availability, > performance, and cost, and we will really listen. We are convinced these > conditions cannot be met today. Hope is eternal! Fuses? The problem then moves to test, but it's been done. ---- KeithArticle: 43114
I would like to announce an LGPLed RISC CPU core written in 100% VHDL. It is available for download from: http://www.etek.chalmers.se/~e8johan/concert02/index.html Please try it out, and give feedback! Best Regards! /JohanArticle: 43115
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: 43116
I'm convinced there is an anti-electical engineering field that passes through the lab at regular intervals :) Anyway, here's a little history. When I at first couldn't even get the bus working the PCI33_5 standard to work it appeared we had no problems with voltage levels. Everything was at 3.3V which should have been enough for the ISA bus, but our erros clearly indicated we were getting stuck at zero errors beause all of our erroneous data was values that could be derived from the input simply by dropping some of the 1's to 0's. However, we could never see these ourselves. This is why I decided to add the 4.7k ohm pull-up resistors so the bus would go to a full 5V. This worked, and the bus began to operate. Last week (well, two weeks ago now), I had finished the project but was messing around with it some more and discovered that now it worked without the pull-up resistors. I haven't bothered to look at it with a scope lately since the last time I did it we couldn't see anything that should have been causing abnormal operation in the first place. Two weeks ago I also discovered that LVTTL doesn't work at all. I had originally switched from LVTTL to PCI33_5 because I was basing my core off of one from a part at Mesa Electronics, in which they used PCI33_5. (They were also trying to assign slew rate and drive current via the contraint file, but I don't think that's possible with PCI33_5, only with the LVTTL io buffers). Anyway, I just stuck with the PCI33_5 since I knew someone else had gotten the bus working using it. The LVTTL not working is a mystery to me though. The behavior it exhibits is this. I have a C++ programming writing and reading a value into the FPGA. It reports the success or failure of each write and read (whether it read the same thing it just wrote into the FPGA) into a file along with the the value of each write and read transaction. I'm doing 8-bit transactions at the moment so I basically just have a counter that counts from 0 - 255 and writes and reads the value. As I said, the implementation using PCI33_5 works fine, success every time. However, the LVTTL log file is a string of all failures except for the first one. This is because the LVTTL port always gives me a value of zero on a read, and the first test value is always a zero so it says it is correct. Of course, it doesn't help to have a port that only lets the PC read in a zero regardless of the actual data value. Occasionlly, no more than once through each run, I will see something other than a zero on one of the PC reads, but it's never the correct value anyway, so it still results in an error. These are just noteworthy merely because it's not just a zero. This occurs even when I have the pull-up resistors to 5V on the bus so it can't be merely a voltage level issue. I wouldn't expect that anyway since it's for the most part a consistant zero on the port and not some random derivative of the input value with some random stuck at zero faults. I also know it's not my logic as I use the same VHDL and C++ code for both tests, I just synthesize one using PCI33_5 and one using LVTTL. I guess my only other course of action is to try and delve in with the oscilloscope again. It didn't really tell me anything useful last time so I have my doubts. If I knew the drive current that PCI33_5 uses though I may not even have to worry about the LVTTL though. So if anyone knows what the standard drive current on a PCI33_5 output buffer is I'd be grateful, since I can't seem to find it anywhere :) Peter Alfke <palfke@earthlink.net> wrote in message news:<3CE088A5.5CE49203@earthlink.net>... > Rick Filipkiewicz wrote: > > > > > ... unless they're being eaten by the great metastability beast. Maybe the > > work/!work is related to seasonal variation in lab temperature :-). > > Sure, but then I am looking for: > "Works mostly, but not al low Vcc or at hot, or at cold, or..." > Or: "works in some devices, but not in all..." > Or" works only when I put 100 pF across the clock line..." > > "Does not work" is like going to the doctor and saying "I am sick". > Complete lack of information... > > Peter AlfkeArticle: 43117
This is a multi-part message in MIME format. --------------9817F37E2EE05A8A19E8E907 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Venu, If you have not done so already, please create a case with our hotline for this so that it can be properly investigated. If there is a problem with the way we are creating our simulation models, we would like to know the details about it so that this can be fixed for future revisions of the software. The best work-around I can offer you without knowing more about your specific problem is to disable the X_SUH generation in the netlist. To do this, set the following environment variable to 1 and re-run the ngdanno and ngd2ver portions of the design run: XIL_ANNO_DISABLE_GSUH If this environment variable is enabled, no X_SUH components will be created in the netlist. This would mean that possible setup or hold conditions for signals entering the design may not be detected by the simulation so careful static timing analysis for the input paths of the design becomes that much more important however you should no longer see any warnings from these signals during simulation. -- Brian Venu wrote: > Hi, > > I am having a problem in verilog back-annotated simulations as > described below.Many thanks to anyone who can suggest a workaround. > Everything was O.K > with earlier versions of Xilinx SW and hence design issues are ruled > out. > > In my design , I take Clk_66 as input and internally generate > Clk_132 using > DCM and external feedback. > Some of the I/O's of FPGA are driven by logic running at Clk_66 > while > some other by logic running at Clk_132. My problem is that > Xilinx verilog writer has added X_SUH elements for all the I/O's > with clk as > Clk_66..This is resulting in a setup violation being reported for > all Clk_133 > inputs. The PAR does not report any static timing violations. > > Please let me know if anyone has encountered something similar. > > Thanks > VenuArticle: 43118
John Williams a écrit : > > "Robert O. Taniman" wrote: >> > [snip] > >> To John, I'm interested in your 'self memo' about registering the >> counter. Is it possible for you to show your revised code here? > > Hi Robert, > > Sure. I also make use of the idea from swier about default output > values at the top of the case statement, you'll see what i mean > from the > attached code. It's still pretty long but you'll see quickly what > it's > doing. Ask if you'd like some clarification. > > Cheers, > > John > Hi John, May I suggest that you add D_in, data and pointer to the sensitivity list of your state_update process? Regards, Renaud. -- Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13 Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 | Mel : pacalet@enst.fr ###### Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/ ######Article: 43119
This is a multi-part message in MIME format. --------------64CA60687ADA50298019B0EC Content-Type: multipart/alternative; boundary="------------E63CB36E349C785E6CBF002A" --------------E63CB36E349C785E6CBF002A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Petter, I am not an expert on SmartModels but I believe I can answer most of your questions below. Petter Gustad wrote: > I'm trying to figure out where to locate the RocketIO swift models to > simulate RocketIO using Synopsys VCS or Cadence Verilog under SPARC > Solaris 8. > > Answers Database #14019 mentiones the Virtex-II Pro Developers kit > (V2PRO). However, the ISE 4.2iSP2 appears to have a GT_SWIFT > installation under > verilog/smartmodel/sol/wrappers/vcs/GT_SWIFT.swift.v > > The problem is that I can't find any instructions on how to use it, > i.e. which object file can I link into my simulator. > > AD#14019 specifies a library file in the V2PRO under > verilog/smartmodel/sol/installed/lib/sun4Solaris.lib, but this file > does not seem to exist under ISE 4.2iSP2. > > 1) Is the Virtex-II Pro Developers kit required to simulate the > RocketIO interfaces? Unless I am mistaken, you do not need the Developers kit for this if you have 4.2i installed. The intention of the Developers kit was to support people using the V-II Pro devices before the 4.2i release was available. > 2) If not, which library/object file supplied with ISE 4.2iSP2 do I > use? You must install the simulations files. To find the instructions to do so, look at: Answer Record # 14595: 4.2i SmartModel installation - How do I install the PPC and MGT SmartModels that are included in the 4.2i Implementation Tools? This will instruct you how to run the Logic Modeling sl_admin tool and properly install the models. After running this, you should see the verilog/smartmodel/sol/installed/lib/sun4Solaris.lib library you were missing before. > 3) Further there is a x86_linux directory containing som Linux X86 > binaries under verilog/smartmodel/sol/image. Is, or will Linux X86 > swift models be supplied so I can run my simulations on Synopsys > VCS or Cadence Verilog under Linux X86? We do not supply a Linux model (yet). I believe that directory is a part of the Logic Modeling tool and not a part of the Xilinx software itself. If you are interested in using a Linux OS simulator, let me know which simulator you are interested in. I can not make any promises, however if there is enough demand, we may be able to provide these in the future but for now, there is no plan to provide a Linux version anytime soon. We are supporting MTI on Windows and the Solaris versions of MTI, Cadence NC and Verilog-XL, and Synopsys VCS. Since models and wrapper files need to be specially made and tested for each simulator / OS version, we sould not support them all. > BTW. I'm familiar with swift models since I have used VMC to generate > swift models of my own ASIC designs. Good. Then hopefully the information above is enough to get you going. Using these SWIFT models is certainly not as easy to use as standard HDL but once you get it installed and running, things go pretty smooth. -- Brian > > > Petter > -- > ________________________________________________________________________ > Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 43120
Bert Wibble wrote:
> 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.
Do a google search on
[ differential driver ]
and on
[ phase lock loop clock ]
-- Mike Treseler
Article: 43121Use multiple outputs with the same driver. Keep output skew to a minimum with adjecent IOBs or Macrocells. emanuel stiebler wrote: > Hi all, > anybody out here knows a CPLD/FPGA which can sink at least 50 mA > on a 5V TTL compatible output ? > > cheers & thanksArticle: 43122
Hi, a question about place and route. I have tried to bring a small design (300 LUTs, 500 FFs) to a Virtex-2-6000 FPGA using Alliance 4.1 tools on Solaris. The design shold be placed in an rectangular area of the slice array, so I specified a bounding box of sufficient size in the ucf file (using the LOC constraint). During PAR, there is no error message at all, but it seems PAR is not interested in the LOC constraint. A handful of the slices is placed in the bounding box, but the majority is placed somewhere on the chip. If I add -pl 5 -xe 2 to the PAR command line, the results become better, but some slices are still missplaced, although the size of the bounding box is sufficient. (If the box is to small, PAR generates an error message). When I used placement constraints for a Virtex1000 in the 3.1i software, I had none of these problems. Any Idea? Thanks, Marcus. -- -------------------------------------------- Marcus Bednara (mailto:bednara@date.upb.de) Computer Engineering Lab (AG Datentechnik) University of Paderborn, Germany Phone ++49-(0)5251-60-3921 URL: http://www-date.upb.de/~bednara --------------------------------------------Article: 43123
>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. I think you are going to be in trouble until you constrain the timing on the two clocks. I know of two ways to attack this problem. One is to make both clocks in the same clock generator chip (low skew to start with) and then adjust the data out of the FPGA to meet setup/hold. You have to account for the lengths of the two clock traces, but you can use that to shift your clock by making one trace longer/shorter than the other. (PCBs are reasonably stable.) You also have to consider the length of the data traces from FPGA to DAC. The other way is to make the DAC clock in the FPGA. If the clock and data traces from FPGA to DAC are the same length the delay doesn't change the setup/hold. Note that this adds the DLL jitter to your DAC clock which will probably add too much distortion to your final signal. -- 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: 43124
If you parallel outputs for high current sink (!), then it is best to configure all outputs as "open collector". This avoids contention during the very short time that the outputs might disagree. Peter Alfke ============================ John_H wrote: > Use multiple outputs with the same driver. > Keep output skew to a minimum with adjecent IOBs or Macrocells. > > emanuel stiebler wrote: > > > Hi all, > > anybody out here knows a CPLD/FPGA which can sink at least 50 mA > > on a 5V TTL compatible output ? > > > > cheers & thanks
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