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
HI I would like to confirm that my flow is correct. I am checking the Power consumption of some final state machines. The begining is the kiss file with the state machine, next I am encoding and synthetizing it with SIS (berkeley university product) tool. After that I am receiving the blif file. Using our own tool I am converting this blif to edif which is full yrecognizable by the ISE tool. I am making mapping of this edif, generating testbench simulating it with modelsim and when I hav .vcd file from model sim I am using the xpower tool. The results for this files are mostly resonable or inaccurate. When I checked the same flow with our own tool most of the results is accurate and only some of them is inaccurate. Do you when can be the problem?? If my explanation is not full just let me know, then I will highlight the points which are not clear. thank you in advance regrads Dominik Gawlowski Brendan Cullen wrote: > Hi Mukesh, > > Mukesh wrote: > > >>Before using xpower for my design, I decide to check for a simple >>design of fibonacci series. I am facing following issues: >> >>I am running xpower with vcd generated with post par simulation and >>during parsing I encounter the following warnings: >> >>WARNING:Power:91 - Can't change frequency of net CLK_BUFGP/IBUFG to >>741.84Mhz. >>WARNING:Power:91 - Can't change frequency of net CLK_BUFGP to >>741.84Mhz. >>WARNING:Power:91 - Can't change frequency of net CLK_BUFGP/IBUFG to >>741.84Mhz. >>WARNING:Power:91 - Can't change frequency of net CLK_BUFGP to >>741.84Mhz. >>... >> >>The frequency for signals in data view shows some values inthe range >>of 2-9% in all cases except CLK_BUFGP/IBUFGP and CLK_BUFGP.. Any >>attempts to change this value results in power:91 warnings as above. >> >>The confidence level shows Accurate. I am confused as the report shows >>zero power for clock/ logic nets and still the confidence level is >>accurate. >>The report summary is : >> >>Total estimated power consumption: 439 >>Peak Power consumption: 1081711 >> --- >> Vccint 1.50V: 65 98 >> Vccaux 3.30V: 100 330 >> Vcco33 3.30V: 3 11 >> --- >> Clocks: 0 0 >> Inputs: 0 0 >> Logic: 0 0 >> Outputs: >> Vcco33 2 8 >> Signals: 0 0 >> --- >> Quiescent Vccint 1.50V: 65 98 >> Quiescent Vccaux 3.30V: 100 330 >> Quiescent Vcco33 3.30V: 1 3 >> >>Whats going wrong here? Anybody encountered similar problems? >>Feedback/ help from Xilinx folks please. >> >>-- >>Mukesh > > > This does indeed look similar to another problem which we've been working > on. We have a fix for that problem (the one we've been working on) and > the fix will be available in the next service pack - 6.3.01i - which > should be available to you next week. However, you might be experiencing > a diferent symptiom. One option would be for you to zip up the NCD & VCD > file and send them to us ? Or are they huge ? The other option is for > you to try the service pack next week. Note - in order for you to use > 6.3.01i you'll need to have the underlying 6.3i. (From your other e-mail > to the newsgroup it appears you are using 6.2.03i.) > > Brendan > >Article: 73576
"Symon" <symon_brewer@hotmail.com>: > ...or at least take all the high speed serial stuff into one FPGA and > distribute it from that one to the others at a slower parallel rate. ok, I agree on that and it might be a good approach to minimize skewing in the first section. but nevertheless I must synchronize the other FPGAs to each other, not at a rate of several GHz but say at ca. 300 MHz. In my opinion a central clock isn't an appropriate solution!?Article: 73577
In article <4153A8ED.D72961FB@yahoo.com>, rickman <john@bluepal.net> wrote: >Nicholas Weaver wrote: >> >> In article <41525983.F7389D7E@yahoo.com>, rickman <john@bluepal.net> wrote: >> >I don't need to see the transistors, just a signal that they control. >> >That would be in the metal. It may be hard to sort out, but I am sure >> >that is orders of magnitude easier than cracking the key by brute >> >force. >> >> However, those signals are still buried under 8 layers of metal, in a >> flip-chip package, with live SRAM cells. > >Please explain this. The outputs from the RAM cells never leave the >lowest layer of metal? The output of the encryptor's ram cells only go to the encryption engine itself, and if I was a paranoid designer, that would be a 2-3 layer metal design, with layers 4-9 on top of it with other stuff to make probing difficult. I can't confirm, not knowing the design, but I'd lay good odds that the bitfile decryption engine is right next to the key storage, and that nothing really goes above layer 3, with layers 4-9 being used for other signals, power, ground, etc. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 73578
Nicholas Weaver wrote: > > In article <4153A8ED.D72961FB@yahoo.com>, rickman <john@bluepal.net> wrote: > >Nicholas Weaver wrote: > >> > >> In article <41525983.F7389D7E@yahoo.com>, rickman <john@bluepal.net> wrote: > >> >I don't need to see the transistors, just a signal that they control. > >> >That would be in the metal. It may be hard to sort out, but I am sure > >> >that is orders of magnitude easier than cracking the key by brute > >> >force. > >> > >> However, those signals are still buried under 8 layers of metal, in a > >> flip-chip package, with live SRAM cells. > > > >Please explain this. The outputs from the RAM cells never leave the > >lowest layer of metal? > > The output of the encryptor's ram cells only go to the encryption > engine itself, and if I was a paranoid designer, that would be a 2-3 > layer metal design, with layers 4-9 on top of it with other stuff to > make probing difficult. > > I can't confirm, not knowing the design, but I'd lay good odds that > the bitfile decryption engine is right next to the key storage, and > that nothing really goes above layer 3, with layers 4-9 being used for > other signals, power, ground, etc. So does that make them invisble? You only need to probe the device with battery power, not main power. So everything that is not powered by the battery is at gnd potential. I would be willing to bet that you can still see between the top level runs. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73579
Think about what a central clock entails from purely a routing perspective. Let's assume you're an SI wizard, and have no issues there. 300 MHz would be ~ 3.3 ns per clock cycle. If I remember my rule of thumb, you've got about 6 inches per 1 ns for the speed of an electrical signal in FR-4 material. So the worst case match between all your data lines and all clock lines for all FPGA's will be the skew that eats into your timing budget. Just as an example (I'm not really a layout person, so it's my posterior speaking), matching all lines to 4 FPGAs +/- 3 inches seems relatively tricky, but not completely unreasonable. So now ~1/3 of your entire clock cycle is wasted (more, if you were assuming DDR) before you even get to the FPGA fabric. it makes laying out your design that much more tricky. Now, in the slightly more real world you've got to throw in the jitter present on a 300 MHz clock, impedance mismatches causing reflections, crosstalk on your board with all that data zipping around (because GHz and even 300 MHz lines are really antennae) and you've got a lot to deal with. Anyhow, synchronzing dataflow at those speeds on a PCB is not nearly as simple as just plopping down a clock. It's a hard design, but you get to choose where to place the burden. If you've got really good PCB people, maybe they can match and terminate the really well. If you've got the DCM/ DLL (or their altera, or "insert brand" counterpart) hardware to de-skew the board clock, you could let the FPGA do it (though I don't recall at what frequencies the DCM's top out). If you've got neither, you might want to consider going to a single chip serial interface, because you're going to get into trouble otherwise. --Josh "Leroy Tanner" <ikeepthespiritalive@freenet.de> wrote in message news:cj1476$9pc$1@mamenchi.zrz.TU-Berlin.DE... > > "Symon" <symon_brewer@hotmail.com>: > > ...or at least take all the high speed serial stuff into one FPGA and > > distribute it from that one to the others at a slower parallel rate. > > ok, I agree on that and it might be a good approach to minimize skewing in > the first section. but nevertheless I must synchronize the other FPGAs to > each other, not at a rate of several GHz but say at ca. 300 MHz. In my > opinion a central clock isn't an appropriate solution!? > >Article: 73580
Simon wrote: > Well, if webpack supports the XC3S1000/1500, will BaseX do the same ? > I've recently bought BaseX (no sign of any upgrade in the post, mind, > even though I've registered it etc...) but had resigned myself to using > a '400 part because there's no way I could justify $3k (after tax/import > duty/shipping) for Foundation. I'll be a bit miffed if the free version > can do more than the pay-for version though... They probably still working on the features ;-) If you look at the online shop, the WebPack has the support for the xc3s1000 & xc3s1500. If you download the comaprison chart, the support in WebPack is not there for the xc3s100 & xc3s1500. So, less value if you pay for it ? Xilinx, are you listening ? It would be nice, if both packages would have the xc3s1000 & xc3s1500 support in them ...Article: 73581
Thanks for commenting. It's unfortunate that the way the postings were made it appeared that only item #2 applied and that that was violated. It was pointed out late in the thread that you were (probably) responding to the Stratix-II vs Virtex-4 thread where a Xilinx professional highlighted the strong points (as he knows them) of the Virtex-4 and left the discussion of the Stratix-II to Altera. To "reactively respond" would be to post a followup to that conversation. In keeping with the train of that discussion, it would have made sense to highlight the positives of the Stratix-II - as in the August news release by Altera's Senior VP of marketing http://biz.yahoo.com/prnews/040830/sfm083_1.html - rather than to suggest the competition is doing things so terribly wrong which seemed to be the majority of the post. The post appeared to be competitive attacks rather than product commentary. If you can provide reasoned insight into the Altera products and directions, your input is welcome on this board. Really. Just please be part of a discussion - an existing thread - and keep the issues to the technical items that affect the lives of designers. Engineers see much of marketing as "fluff" so the need to contribute should be minor. And read the newsgroup when you have a chance. "Dave Greenfield" <davidg@altera.com> wrote in message news:5c156a0b.0409231601.32cec67d@posting.google.com... > Now that the dust is starting to settle, I'd like to highlight the > guidelines that Altera uses in involvement with this newsgroup. > > 1) We reactively respond to customer questions on both marketing and > technical issues (if it is a marketing response, we may use a > marketing person and clearly articulate the title of the poster). > 2) We do not proactively start posts about our new products. > 3) We respond to competitive commentary on our products, as not doing > so implies agreement. > 4) We refrain from personal attacks. > 5) We refrain from competitive attacks unless provoked. > > My responses earlier this week addressed points 1, 3, and 5 above. > There clearly are additional un-written guidelines with this > newsgroup, and if I have offended anyone with my overt rather than > covert marketing, I offer my apology. Thank you for the newsgroup > etiquette training. > > Dave Greenfield > Sr. Director of Propaganda & Ilk > Altera CorporationArticle: 73582
In article <41543695.30F6A736@yahoo.com>, rickman <john@bluepal.net> wrote: >So does that make them invisble? You only need to probe the device with >battery power, not main power. So everything that is not powered by the >battery is at gnd potential. I would be willing to bet that you can >still see between the top level runs. The cells are static, so you can't track dynamic power which would make it easier. So you need to probe static signals buried under 4-8 layers of metal, without disrupting the battery power. You could drill down, but that's going to be annoying, especially since if it were me, layer 3 & 4 would be a crisscrossing grid of battery power/gnd links (I don't know if they do that, but I would). Frankly, it is probably going to be vastly easier to do a sidechannel analysis on encryptor power & EM signature, at least my gut thinks so, or drill down to the CONFIG wires and just read the config as its loaded, as the config info has to go everywhere. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 73583
I bought a Spartan-3 Starter board as well as the AIO1 fomr Digilent that was suggested. Thus far I have gotten some good results with the Starter board alone and begining to learn some vhdl, altho still very foggy in some areas, as to be expected. Now, I would like ot intergrate the AIO1 board. I have everyhting set up and know which pin my Digital Data is coming in on, but thats were im stuck. How would I go about getting that Digital data and turning it into something useful, just even a basic multimeter type application. As well are there any examples of this online(taking a digital in line and seeing what the data it)? Thank you very much for your time! WeizboxArticle: 73584
Hello, I have found a problem with a C++ Code, if i have a Buffer of "unsigned char" (for example 00 00 00 00 37 00 00 20 00 ecc..ecc.) ,i want to get a DWORD value from the 5 byte they should be return 00 00 20 00 sequence, instead they give me the result from 37.... (a 4 bytes pairs)... if i try from 6 or 7 byte , they returned me the same value , also from the 8 byte give me a new correct value.. the Nios can't addressing the offset of 4bytes? , the same code compiled on pc work great.. Thank's a lotArticle: 73585
Nios II version 1.0 SP1, just released, contains a new software
example design called "memtest". This example design checks using
#ifdef to see if the system contains a DMA. If it does, it performs a
test of memory using HAL DMA code in addition to the normal tests it
runs. Pasted below is a copy of the DMA test function which includes
calls to the DMA HAL routines.
-Nathan Knight
Altera Applications
/******************************************************************
* Function: MemDMATest
*
* Purpose: Tests every bit in the memory device within the
* specified address range using DMA. The DMA controller provides
* a more rigourous test of the memory since it performs back-to-
* back memory accesses at full system speed.
*
******************************************************************/
#ifdef DMA_NAME
static int MemDMATest(unsigned int memory_base, unsigned int nBytes)
{
int rc;
int ret_code = 0;
int pattern, offset;
alt_dma_txchan txchan;
alt_dma_rxchan rxchan;
void* data_written;
void* data_read;
/* Get a couple buffers for the test */
/* Using the "uncached" version of malloc to avoid cache coherency
issues */
data_written = (void*)alt_uncached_malloc(0x1000);
data_read = (void*)alt_uncached_malloc(0x1000);
/* Fill write buffer with known values */
for (pattern = 1, offset = 0; offset < sizeof(data_written);
pattern++, offset+=4)
{
IOWR_32DIRECT((int)data_written, offset, pattern);
}
/* Create the transmit channel */
if ((txchan = alt_dma_txchan_open("/dev/dma")) == NULL)
{
printf ("Failed to open transmit channel\n");
exit (1);
}
/* Create the receive channel */
if ((rxchan = alt_dma_rxchan_open("/dev/dma")) == NULL)
{
printf ("Failed to open receive channel\n");
exit (1);
}
for(offset = memory_base; offset < (memory_base + nBytes); offset +=
0x1000)
{
/* Use DMA to transfer from write buffer to memory under test */
/* Post the transmit request */
if ((rc = alt_dma_txchan_send (txchan, data_written, 0x1000, NULL,
NULL)) < 0)
{
printf ("Failed to post transmit request, reason = %i\n", rc);
exit (1);
}
/* Post the receive request */
if ((rc = alt_dma_rxchan_prepare (rxchan, (void*)offset, 0x1000,
dma_done, NULL)) < 0)
{
printf ("Failed to post read request, reason = %i\n", rc);
exit (1);
}
/* Wait for transfer to complete */
while (!rx_done);
rx_done = 0;
/* Clear the read buffer before we fill it */
memset(data_read, 0, 0x1000);
/* Use DMA to read data back into read buffer from memory under
test */
/* Post the transmit request */
if ((rc = alt_dma_txchan_send (txchan, (void*)offset, 0x1000,
NULL, NULL)) < 0)
{
printf ("Failed to post transmit request, reason = %i\n", rc);
exit (1);
}
/* Post the receive request */
if ((rc = alt_dma_rxchan_prepare (rxchan, data_read, 0x1000,
dma_done, NULL)) < 0)
{
printf ("Failed to post read request, reason = %i\n", rc);
exit (1);
}
/* Wait for transfer to complete */
while (!rx_done);
rx_done = 0;
if (memcmp(data_written, data_read, 0x1000))
{
ret_code = offset;
break;
}
}
alt_uncached_free(data_written);
alt_uncached_free(data_read);
return ret_code;
}
#endif /* DMA_NAME */
Article: 73586On Fri, 2004-09-24 at 09:01 -0700, weizbox wrote: > I bought a Spartan-3 Starter board as well as the AIO1 fomr Digilent > that was suggested. Thus far I have gotten some good results with the > Starter board alone and begining to learn some vhdl, altho still very > foggy in some areas, as to be expected. > > Now, I would like ot intergrate the AIO1 board. I have everyhting set > up and know which pin my Digital Data is coming in on, but thats were > im stuck. How would I go about getting that Digital data and turning > it into something useful, just even a basic multimeter type > application. As well are there any examples of this online(taking a > digital in line and seeing what the data it)? > > Thank you very much for your time! > Weizbox You need to read the datasheet for the A2D convertor on that board. I think it is an Analog Devices part. There will be a timing diagram that shown how to request a conversion and how to clock out the data serially. Then you will need to write a simple controller to read the data serially and convert into parallel form and perhaps store into a register. This would basically be a state machine and a shift register. Now if you want to make a multimeter, the data in parallel form would need to be converted to a voltage level and then decimal form for display on 7-segment led perhaps. The easy way to do that would be to construct a 256 entry table in block ram that is addressed using the A2D data. The block ram is preloaded with decimal values based on calibration curves you generated on the A2D.Article: 73587
> From: "Tim" <tim@rockylogic.com.nooospam.com> > Newsgroups: comp.arch.fpga > Date: Fri, 24 Sep 2004 01:19:09 +0100 > > I would rather like to see technical posts on new products. > Xilinx used to have a section in their data sheets on how this > generation/product differs from the previous generation/product > and something along those lines would probably be of interest > to a large fraction of the readership of the newsgroup. > > Maybe of special interest to those of us designing products > while trying to keep broadly up to date on the technology... You asked for it, you get it, although it is quite long... I did this for several device generations while I was responsible for data sheets, and I did it again last month, but only circulated it within the company. Note that this is one man's slightly biased view, meant for friends and not for attack dogs...I am most impressed by the I/O and clocking enhancements, by the FIFO option, and the versatile DSP slice (cascadable multiply-accumulator). =================================================================== Virtex-4 for the Experienced Virtex-II and Virtex-IIPro User By Peter Alfke, 8-26, 2004 Virtex-4 offers about 100 innovations, and it may be heresy to compare it to its predecessors, but here is an attempt: Technology: 90 nm triple-oxide process (three different oxide thicknesses plus different transistor thresholds) optimizes the trade-off between speed, leakage current, and I/O voltage tolerance . Vccint is now 1.2 V. Lower static leakage and dynamic current for any conventional logic implementation, and drastically lower power when using the new more highly integrated hard cores (FIFO, EMAC, DSP slices) Structure: Radically different, ASMBL chip layout arranges functions in vertical columns, even the I/O. This allows Xilinx to introduce sub-families with optimized mix between various functions without upsetting architecture or software support. The DSP-oriented SX family has a much higher ratio of multiply-accumulators and BlockRAMs relative to the logic resources in the fabric. Using flip-chip packages, the ASMBL structure also offers better power distribution and lower pin inductance. I/O: Dramatically enhanced capabilities. Each I/O pin has its own serializer/deserializer (Parallel/Serial and S/P converter). DDR interfaces need only one clock and also avoid any 1-bit latency. A 64-stage individually programmable delay line in each input can be used to adjust bit alignment or clock alignment with <80 ps granularity, ideal for source-synchronous interfaces. BitSlip supports word alignment. A high-performance I/O clock can be driven directly from the pc-board. The larger number (9 to 17 depending on chip size) of banks gives better I/O granularity, especially in the larger devices. Configuration now has its own bank. CLBs: faster but no significant structural change. To reduce chip area and to enhance performance, only 50% of the slices have LUTRAM and SRL16 capability. BlockRAM: optional pipeline output registers double performance to 500 MHz. Two BlockRAMs can directly be concatenated for 36K x 1 operation, or for 512 x 72 bit operation with built-in Hamming error correction. The optional hard-coded FIFO controller inside the BlockRAM runs at up to 500 MHz reliably, even with asynchronous read and write clocks. FIFO data bus width, fall-through operation, and the levels of the Almost_EMPTY and Almost_FULL flags are programmable. The FIFO takes up no fabric area, is much faster, much smaller, and much easier to design with than previous soft cores. DSPSlices: Significantly enhanced from the traditional 18 x 18 two¹s complement multipliers. Now include a 48-bit accumulator with three adder inputs and very efficient cascade capability. Clock Management Resources: DCMs are faster, more precise, and have better jitter performance. Two modes: highest speed and finest granularity, or longest delay range. Easy dynamic reconfiguration of phase shift values and M, D. (But M and D changes still require a DCM reset). Phase-Matched Clock Drivers (PMCDs) provide multiple (divided) clock outputs that are delay-matched. Global Clocks: routed differentially, thus faster and less sensitive to crosstalk. Duty cycle is better maintained. More capable BUFGMUX. The Xesium clocking architecture adds high-performance I/O clocks, and a large number of regional clocks. Available in Virtex-4 FX only: PowerPC: runs 12% faster and has new APU co-processor interface with direct connection to processor instruction pipeline. A third-party floating point unit by QinetiQ provides up to 250 megaFLOP performance. Enhanced OCM interface includes I/O handshaking. RocketIO: 0.6 to 11.1 Gbps (wider range than Virtex-IIProX) with additional advanced input equalization options. EMAC: New function, integrates the digital portion of 10/100/1000 Mbps Ethernet Media Access Controller (MAC). Saves over 2000 slices of a soft-core alternative. =========================================================== I hope this is of some interest. Peter Alfke, Xilinx Applications.Article: 73588
Article: 73589
Hi Leroy, Say you've got 4 FPGAs A, B, C & D. Each gets fed the 300MHz clock, so on the fabric of each FPGA is CLK_A, CLK_B etc. When you send data from (say) FPGA B to FPGA D, send a clock with the data, generated by FPGA B from its internal CLK_B, called (say) CLK_B_TO_D. Use this source synchronous clock with a DCM in FPGA D to get the data into a BRAM FIFO inside FPGA D. Get the data out from this FIFO into the fabric of FPGA D using CLK_D. Repeat for all the other paths. Any good? Cheers, Syms. "Leroy Tanner" <ikeepthespiritalive@freenet.de> wrote in message news:cj1476$9pc$1@mamenchi.zrz.TU-Berlin.DE... > > "Symon" <symon_brewer@hotmail.com>: > > ...or at least take all the high speed serial stuff into one FPGA and > > distribute it from that one to the others at a slower parallel rate. > > ok, I agree on that and it might be a good approach to minimize skewing in > the first section. but nevertheless I must synchronize the other FPGAs to > each other, not at a rate of several GHz but say at ca. 300 MHz. In my > opinion a central clock isn't an appropriate solution!? > >Article: 73590
Thanks for a push in the right direction! The board is connected right now as a duaghter board, would this be serial, or rs232 serial? sorry for the seemingly simple questions but this is entirley new to me. As well do you now of any good sites to help me get started with somthing like this and fpga/vdl in general? Thanks!Article: 73591
Luigi Padovani wrote: (snip) > if i have a Buffer of "unsigned char" (for example 00 00 00 00 37 00 00 20 > 00 ecc..ecc.) ,i want to get a DWORD value from the 5 byte they should be > return 00 00 20 00 sequence, instead they give me the result from 37.... (a > 4 bytes pairs)... if i try from 6 or 7 byte , they returned me the same > value , also from the 8 byte give me a new correct value.. the Nios can't > addressing the offset of 4bytes? , the same code compiled on pc work great.. Many machines require data to be aligned on a boundary matching the size of the data. A four byte DWORD should have an address that is a multiple of four. Yes, x86 doesn't require that but it is much slower when doing a fetch like that. It is not legal in C, and I don't believe in C++ to do that. Copy it character by character (memcpy in C) to a properly aligned variable. -- glenArticle: 73592
It's my fault. Based on excellent availability of Spartan3 devices, I made a last minute decision to add the 3S1000 and 3S1500 to the WebPACK. Unfortunately, this was right after the CDs were created. In 7.1i (Feb '05), BaseX will include these devices. If you are a BaseX customer and need access to these devices, send me an email and I'll work something out for you. I'm travelling today, so don't expect a response until Monday Steve E.S. wrote: > Simon wrote: > >> Well, if webpack supports the XC3S1000/1500, will BaseX do the same ? >> I've recently bought BaseX (no sign of any upgrade in the post, mind, >> even though I've registered it etc...) but had resigned myself to >> using a '400 part because there's no way I could justify $3k (after >> tax/import duty/shipping) for Foundation. I'll be a bit miffed if the >> free version can do more than the pay-for version though... > > > They probably still working on the features ;-) > If you look at the online shop, the WebPack has the support for the > xc3s1000 & xc3s1500. If you download the comaprison chart, the support > in WebPack is not there for the xc3s100 & xc3s1500. > > So, less value if you pay for it ? > > Xilinx, are you listening ? > > It would be nice, if both packages would have the xc3s1000 & xc3s1500 > support in them ... > >Article: 73593
Nicholas Weaver wrote: > > In article <41543695.30F6A736@yahoo.com>, rickman <john@bluepal.net> wrote: > >So does that make them invisble? You only need to probe the device with > >battery power, not main power. So everything that is not powered by the > >battery is at gnd potential. I would be willing to bet that you can > >still see between the top level runs. > > The cells are static, so you can't track dynamic power which would > make it easier. So you need to probe static signals buried under 4-8 > layers of metal, without disrupting the battery power. I think you may not understand how em viewing of signals works. Signals with a positive voltage are bright and everything else is dim. The field of the positive tracks will attract electrons, even through the oxide and other metal. It is the field that is visualized, not the metal itself. Of course being deeply buried will make the field distorted, but I bet that would not obliterate the image enough that you can't distinguish the bits. This might be a useful research topic. If the bounty were say, $10,000, it might result in a few people cracking it. I don't think many will bother testing the Xilinx chips security for a couple of hundred dollars. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73594
user@domain.invalid wrote in message news:<cj102r$het$1@news.tue.nl>... > Hello > > I have some state machines in kiss which I am converting to the verilog > format. I would like to encode this verilog with binary, 1-hot, jedi and > gray and after that to synthetize them in ISE. Jedi is easy. Run XST with the -force option. Cheers, JonArticle: 73595
Im reading up on some of it now and was getting confused.. does teh ADC output a clock or do you give it a clock to use?Article: 73596
>Im reading up on some of it now and was getting confused.. > does teh ADC output a clock or do you give it a clock to use? What does the data sheet say? (Some of them can run either way - depends on mode bits.) -- 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: 73597
> About >write timing: Some SRAMS need a data hold after rising edge of nwe. Your >timing between data out and nwe depends on the routing. To not waste an >additional clock cycle on write I've used a neg-edge triggered FF for the >nwe signal. Check the fine print in the data sheet. If you just advance the we signal by clocking on the other edge, (that is move it earlier without changing the duration) you may not meet address setup times. (Which means the chip might write something to the wrong address(es).) I agree that it would probably be simpler to get something working slowly at first. Writes generally work cleanly at 3 cycles: one for setup, one for active, and one for hold. (Add a dead cycle between reads and writes to turn the bus around.) -- 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: 73598
I looked at the sheet and now i belive it wants a signal.. i think. The confusing part is when I look at the datasheet for the AD7823 and the AIO1, the seem to do some weird things. The CONVST label on the ADC changes over to ADCLK when it gets to the pinout, as well SCLK on the ADC changes to CONVST? Not sure why.... may take a few trial and errors to figure out what pins do what unfortunetly, or mabye Im reading it wrong...Article: 73599
I am looking for an LCD model which i can use as a test bench for my simulations. Any ideas where i might be able to find one. 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