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
On 12 juil, 20:21, ghel...@lycos.com wrote: > On Jul 11, 5:46 pm, Totally_Lost <air_b...@yahoo.com> wrote: > > > > > > > On Jul 11, 5:41 pm, Jim Granville <no.s...@designtools.maps.co.nz> > > wrote: > > > > The specific example here was a 3rd party tool flow issue, and quite > > > a long time ago. As a 3rd party issue it is not entirely Xilinx's fau= lt. > > > It even seemed there was a design solution, just no longer free. > > > The specific issue was ISE and it's synthesis tool, and that Xilinx > > terminated a 3rd party agreement and went inhouse with XST, failing to > > provide continutity of synthesis ability for existing registered users > > of ISE because they didn't want to spend the money to include XC4K > > support in XST. > > > That was a breach of contract for registered ISE users like myself at > > the time, as when I asked for a new license, they were unable to > > deliver an alternate synthesis for the product I purchased when they > > terminated the 3rd party contract. > > > It's in this specific context that Austin's statements are a clear > > missrepresentation. That XC4K business decison by Xilinx cost me > > dearly, almost loosing my home, and business. So when he slams their > > competitors and states Xilinx has always taken the mornal high ground > > here, and never caused their customers concern about product > > support .... let's just agree, that is a lie. > > > The point is, that Xilinx could have included XC4K support in XST, and > > by choosing not do, caused thousands of Xilinx users (including many > > students with XC4K student boards and educational ISE licenses) an > > clear economic loss from the decision removing VHDL/Verilog license > > availablity or replacement with XST. > > > So, this is not spin (AKA a politically or socially correct lie) ... > > this is gross missrepresentation by Austin, specifically to place > > Xilinx competitors at a disadvantage, and misslead new Xilinx > > customers about their past. > > I'm confused... > > I distinctly remember many emails from Xilinx about the end of FPGA > Express support, and several options for for the future. > > A perception I had (from those emails) was that it was a rather nasty > divorce. I'm willing to believe that Xilinx did all they could to > support their customers; I got a good deal of help from their support > staff preparing for the future. > > I chose to sand-bag a copy of ISE-4.2 just in case I ever had to fix > any of my Spartan-I or 4K designs. Last time I checked, it worked > just fine; the FPGA-Express license hadn't expired, nor had ISE > stopped working. > > In a way, they did me a favor by dropping support for those devices. > I'm real happy to never do a Spartan-I design ever, ever again. > > G.- Masquer le texte des messages pr=E9c=E9dents - > > - Afficher le texte des messages pr=E9c=E9dents - I think totally_lost is unfair with Xilinx regarding the end of FPGA Express. I remember this story because i used XC4000e board with my students and FPGA Express. What are the facts : in september 2001, Synopsys decided to stop OEM license for FPGA Express then to stop FPGA Express. Synopsys is to blame, not Xilinx. I used ISE 4.3 with Express for years after this time and it still works today. No end of support, perpetual license for Express, no problem at all. In 2006, i decided to design new board with Spartan-3 and switch to ISE 7.1. XC4000 was not supported by XST, that's true but it was still supported by Express and worked perfectly. What is the problem ??? ISE 4.3 still works, Express still works so what ? Where is the crime ? You can still design old FPGA and old board with old software. when i discovered this story, i blamed Synopsys, not xilinx.Article: 121926
On Sun, 15 Jul 2007 09:32:38 GMT, nico@puntnl.niks (Nico Coesel) wrote: >John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >>On Sat, 14 Jul 2007 14:17:53 -0400, krw <krw@att.bizzzz> wrote: >> >>>In article <670i93lg7f1m4jhrcu9l48hjosvoo0jcdv@4ax.com>, >>>jjlarkin@highNOTlandTHIStechnologyPART.com says... >>> >>>> [1] statistical analysis of some FPGA configuration patterns, leading >>>> up to a fast, small compression/decompression algorithm. We need to >>>> fit an application program and 6 megabits of Xilinx config stuff into >>>> a 4 mbit Eprom. >>>> >>>I think Xilinx has some stuff on their site regarding compressing >>>FPGA patters. IIRC, they're quite compressible, easily (RLL or some >>>such). >> >>I'm looking for something that will be fast and easy to decode at fpga >>config time. >> >>I just did some statistical analysis of a bunch of existing Spartan 3 >>bit streams. If you treat them as bytes, and histogram the byte codes, >>there's some impressive stats, with code 0x00 of course dominant, then >>0xFF, and the next 16 most common codes huge, tapering off pretty >>hard. That makes sense, since LUT bits are usually zero, so simple >>codes like 0x01...0x80 and simple 2-bit combos are most common. Block >>ram is usually 0 in our designs, too. So a fixed dictionary should >>work pretty well. >> >>So it looks like a byte stream would do, with byte codes that say >>stuff like... >> >> >>00000000 end of file >> >>001nnnnn make N zero bytes, N=1 to 31 >> >>010nnnnn make N 0xFF bytes, ditto >> >>011nnnnn the following N bytes are raw, unencoded stuff >> >>1nnnnnnn look up code N in dictionary, N = 1 to 127 >> >>where the dictionary is a list of the most common 96 single bytes >>followed by the most common 32 byte pairs. Net compression in this >>case is just about 1:1! >> >>Something like that. >> >>Now the question is, how much compression will this give? I suppose >>I'll have to code it and see. I need less than 2:1 now, and that >>shouldn't be hard. > >Still working on this after 3 years? It was interesting three years ago. This month, it's mandatory. JohnArticle: 121927
On Jul 13, 11:43 pm, "Cla" <c...@sbcglobal.net> wrote: > My company may soon have to put together our first embedded system. > Since we're beginners, we're probably not going to (a) know what we're > doing, > (b) have a good firm set of application requirements, (c) have a lot of > embedded/programming experience. > > The target hardware would most likely be one of the Tensilica 32-bit > cores, or an ARM/922 (probably not an ARM7 TDMI.) > > I realize that makes this question really really loaded, but given the > criteria > of "needs to be maintainable by non linux-gurus", what's the better > embedded O/S choices? Can be commercial or open-source...since we're > willing to pay a little more upfront for (hopefully) eaiser learning curve. It used to be (a long time ago) that the more you paid for your RTOS, the better support you got. It's not that way any more. Realize that because this is your "first time", you will make mistakes. Don't be afraid to toss your 1st choice and try another. Just make sure you don't loose a bunch of money in the process. There are even some "try before you buy" licenses out there. You might find this interesting: <http://www.netrino.com/Articles/ RTOSes/index.php> G.Article: 121928
Pasacco wrote: > ".prj file" contains "library creation and mapping". > Thank you for comment. > > I see following statements in the ".prj" file for one module. > ------------------------------------------------------------------- > -- Generated by GUI > > vhdl submodulelib "../../src/submdule_pkg.p.vhdl" > vhdl submodulelib "../../src/submdule.e.vhdl" > vhdl submodulelib "../../src/submdule_rtl.a.vhdl" > ...... > ------------------------------------------------------------------- > > Suddenly, I am confused. > Let me ask question. > > ".prj file" does not look like a script. > > Suppose we have the ".prj file", > In order to actually "create and map libraries", what is next step to > proceed? > In the "XST User Guide" that comes ISE, there is an entire chapter "Command Line Mode". It discusses most of this. Another helpful place to look for clues is the .syr file, which is a log file for XST. Basically the .prj file is used as the -ifn parameter to the XST command line "run" command.Article: 121929
Nico Coesel wrote: > "Cla" <cla@sbcglobal.net> wrote: > >> My company may soon have to put together our first embedded system. >> Since we're beginners, we're probably not going to (a) know what we're >> doing, >> (b) have a good firm set of application requirements, (c) have a lot of >> embedded/programming experience. >> >> The target hardware would most likely be one of the Tensilica 32-bit >> cores, or an ARM/922 (probably not an ARM7 TDMI.) >> >> I realize that makes this question really really loaded, but given the >> criteria >> of "needs to be maintainable by non linux-gurus", what's the better >> embedded O/S choices? Can be commercial or open-source...since we're >> willing to pay a little more upfront for (hopefully) eaiser learning curve. > > From what I've seen from Windows CE5.0 choose an OS where you have > access to all the source (which isn't the case for WinCE 5.0). You'll > need it to be able to fix bugs! I it where my call, I would choose > Linux. It has a more layered structure which makes it possible to > isolate a problem more quickly. Besides, you can prototype your > software on a PC and then compile it for the embedded platform without > changes. > Linux is fine, but may possibly be overkill. We have had good results with FreeRTOS.Article: 121930
Marc Battyani wrote: > I've just got a brand new board with a Stratix II S180 on it. Before I > power it on, I checked the power supply rails for short-circuits. I get 20 > ohms on the 1.8V supply rail and 1.2 Ohms for the 1.2V. 20 ohms does not > look like a short but 1.2 is rather small. On those supplies, I only have > logic components and decap capacitors, the power supply is on another > board. > > So any advice before I push a few amps in it? Short or not? > (I must say that I'm somewhat stressed by the device price ;-) Marc, 1.2 Ohms is fairly normal for this device. The EP2S90 is about 2 Ohms. You should get worried if it goes below 1 Ohm. Had one customer see 0.2 Ohm - turned out to be a short beween VCCint and PLL ground. Best regards, BenArticle: 121931
On Fri, 13 Jul 2007 15:55:39 +0100, "Tom Lucas" <news@REMOVE_tlcs_THIS_dot_TO_fsnet_REPLY_dot_co.uk> wrote: >"Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message >news:nPGdnWZQAqSCEArbnZ2dnUVZ8vidnZ2d@giganews.com... >> >> "Maurice Branson" <traubenuss@arcor.de> wrote >>> >>> Oay, to make it more precise: I'm looking for an interconnect system >>> (multi-channel plug + receptacle) for 24 differential pairs at >>> signaling rates of 3 - 6 Gbps per channel. >> >> I don't know if you have already looked at them, but for things like >> that, I use Samtec connectors and cables. >> http://samtec.com/high_speed_connectors/2006/si_b2b.asp >> http://samtec.com/high_speed_connectors/2006/SI_C2B.asp?m=hs > >I can recommend Samtec as well - very fast service and samples turn up >in under two days. Knowledgable reps too. > I alos like Samtec, but their prices has been kreeping up over the last number of years. Every time we buy the price is up from the previous time. There are quite a few pretty standard connector families that can take coax pins. D-Type and Din 41612 to name 2. You can also try Nicomatic. They make small connectors which can take coax pins. They can do a custom connector for quite cheap. Less than US$500 if I recall correctly for NRE charges. Regards Anton ErasmusArticle: 121932
--nextPart2819450.cR4Ef3jXsc
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8Bit
John Larkin wrote:
> On Sat, 14 Jul 2007 14:17:53 -0400, krw <krw@att.bizzzz> wrote:
>
>>In article <670i93lg7f1m4jhrcu9l48hjosvoo0jcdv@4ax.com>,
>>jjlarkin@highNOTlandTHIStechnologyPART.com says...
>>
>>> [1] statistical analysis of some FPGA configuration patterns, leading
>>> up to a fast, small compression/decompression algorithm. We need to
>>> fit an application program and 6 megabits of Xilinx config stuff into
>>> a 4 mbit Eprom.
I wrote the following two small C programs in 2001 for an Altera FPGA. You
can't get it much simpler, and from a whole bunch of config files it gets
about a 50% compression factor (plus or minus 15%).
You may need to set the 'most-common value' from 0x00 to 0xff - I don't have
a lot of Xilinx bitstreams here to check what's best.
You could actually check the 'golden' bitstream to count which byte value
occurs the most...
Good luck!
Ben
=============================
/*
* decode.c
*
* Performs run-length decoding on 0-bytes in order
* to retrieve the compressed data stream
*
* Written 17-Oct-2001 by Ben Twijnstra
*
*/
#include <stdio.h>
/* The next three macros make the code a bit more abstract */
#define NEXT_BYTE fgetc(fpi)
#define WRITE_BYTE(a) fputc(a,fpo)
#define LAST_BYTE EOF
main()
{
/* In- and output file pointers */
FILE *fpi, *fpo;
/* The whole three variables needed to do the actual decoding */
int c1, c2, len;
/* Open the files */
fpi = fopen("design10.cmp", "rb");
fpo = fopen("design10.bin", "wb");
/* Here is the actual compression bit */
while ((c1 = NEXT_BYTE) != LAST_BYTE) {
WRITE_BYTE((char) c1);
if ((char) c1 == '\0') {
c2 = NEXT_BYTE;
for (len = 1; len < c2; len++) {
WRITE_BYTE('\0');
}
}
}
/* All done. Now exit gracefully */
fclose(fpi);
fclose(fpo);
}
=============================
/*
* encode.c
*
* Performs run-length encoding on 0-bytes in order
* to compress the data stream
*
* Written 17-Oct-2001 by Ben Twijnstra
*
*/
#include <stdio.h>
/* The next three macros make the code a bit more abstract */
#define NEXT_BYTE fgetc(fpi)
#define WRITE_BYTE(a) fputc(a,fpo)
#define LAST_BYTE EOF
main()
{
/* In- and output file pointers */
FILE *fpi, *fpo;
/* The whole three variables needed to do the actual encoding */
int c1, c2, len;
/* Open the files */
fpi = fopen("design10.sof", "rb");
fpo = fopen("design10.cmp", "wb");
/* Here is the actual compression bit */
while ((c1 = NEXT_BYTE) != LAST_BYTE) {
WRITE_BYTE((char) c1);
if ((char) c1 == '\0') {
len = 1;
while ((c2 = NEXT_BYTE) != LAST_BYTE) {
if ((char) c2 == '\0') {
len++;
if (len == 255) {
WRITE_BYTE((char) len);
break; /* Start another run */
}
} else {
/* End of run. Write out length */
WRITE_BYTE((char) len);
/* and the next char */
WRITE_BYTE((char) c2);
break;
}
}
}
}
/* All done. Now exit gracefully */
fclose(fpi);
fclose(fpo);
}
Article: 121933On Jul 12, 6:29 pm, Patrick Dubois <prdub...@gmail.com> wrote: > On Jul 12, 12:03 am, Yao Sics <yao.s...@gmail.com> wrote: > > > Hi Xilinx Killers, > > > It is really annoying to rename and group all the signals everytime > > when design is modified and new bit file is used to configure the > > fpga. Anybody knows how to avoid renaming and regrouping signals in > > the analyzer when new bit file is loaded to FPGA? > > When adding new signals to a Chipscope project, I try to add them at > the end to avoid screwing up the project. That way you can simply > import your new .cdc file into your Chipscope Analyzer project and all > the previous signals will stay intact (and the new signals will > appear). Avoid inserting new signals by moving other signal positions > around, as this will screw up the project. > > In order to help you setting up the Chipscope Analyzer project, take a > look at csptool:http://code.google.com/p/csptool/ > > It's a little Perl script that regroups buses for you. Might be > overkill if you have a few buses, but if you have tens, it can be very > handy. > > > And one more quick question, how to investigate state_reg of a FSM by > > usingchipscope? Because the original name of the interesting > > state_reg is modified after synthesis, I dont't know which signal I > > should investigate now. > > You can look at the synthesis report to see how XST encoded the > states. Then I suggest that you create a .tok file to display the name > of the state in the waveform window. Look at \ChipScope_Pro_9_1i\bin\nt > \token\token_sample.tok for an example. > > Patrick Hi Patrick, How do I download your script source code? At csptool:http://code.google.com/p/csptool/ I couldn't fine any download files. Thank you. WengArticle: 121934
On Jul 13, 11:43 pm, "Cla" <c...@sbcglobal.net> wrote: > I realize that makes this question really really loaded, but given the > criteria > of "needs to be maintainable by non linux-gurus", what's the better > embedded O/S choices? Can be commercial or open-source...since we're > willing to pay a little more upfront for (hopefully) eaiser learning curve. It seems you assume that a non-Linux OS will be easier to learn and maintain? Considering you will a learning experience no matter which OS you pick, something mainstream like Linux or uCLinux is guaranteed to have better documentation, more people in the world that can help you (either for $$$ or free on Usenet etc), and frankly is likely to fewer bugs. There are pleanty of good reasons to pick something else depending on the circumstances, but given your concerns, Linux clearly seem the best choice. BTW, the Linux learning curve is trivial. TommyArticle: 121935
I am not totally sure if the 0x000c1003 is what is being sent by the
fpga. I don't have a logic analyzer so its hard to tell when the
bitstream starts. On my scope it looks like this:
---------- -- --- ----------------
------- ------ --------------
Which does not exactly correspond 11000001000000000011. I'm not sure
what the id should be and if there is any correlation between what is
read and the correct value.
My scope is only 100mhz, but the edges look really sharp to me. I
doubt the jtag circuits are fast enough to respond to anything above
this speed.
I was using a home made parallel 3. I know people have tons of trouble
with these, but the data going in/out seems to be really clean. Just
in case, i hooked my board into the jtag chain of digilent nexsys
board with a spartan-3e on it. It also has a integrated usb
programmer. My device was shown in the chain with the same garbage id
i see on my parallel 3. When trying to program the other devices, it
fails, leading me to believe the device cannot enter bypass mode.
Is there some combination of tdo,tdi,tms,tck that could be shorted
togeather to cause this? Are these kinds of things symptomatic of a
bad chip. I've also noticied some strange behavior on the
configuration port. The chip is setup to configure over SPI. CCLK is
going, but cso_b never goes low, and mosi never toggles. I've checked
the connections a thousand times.
Article: 121936On Jul 15, 8:44 am, austin <aus...@xilinx.com> wrote: > All, > > The Parallel III cable was built before we had JTAG that had its Vcco > lowered to 2.5V, and a whole slew of features added ... > > http://direct.xilinx.com/bvdocs/userguides/ug332.pdf > > Figure 9-1, has a good schematic of what is going on: input pins > require series resistors, as they all use 2.5 V as their internal Vdd, > output is optionally able to pullup (to Vccaux), see XAPP453. Also note > Table 2-9 in the above referenced document, specifically what the TMSPIN > does (enables, disables pullup to Vccaux internally). > > So, may an older parallel III cable work?: yes, but, you need to have > the series resistors on input, and you need to address the TDO output, > by either setting the TMSPIN to the right state, or providing an > external pullup on TDO. > > The newer cables are 'smart' enough to figure out what to do, even > though there may be settings that are enabling/disabling pullups. > > Austin So are you saying the parallel cable III output is 3.3V? I thought it had a CMOS buffer inside, powered by the red vcc line (2.5V in my case). Also it has 100ohm series resistors and a TDO pullup. I finally found a schematic http://www.xilinx.com/support/programr/files/0380507.pdf Alan NishiokaArticle: 121937
On Jul 15, 12:52 pm, Alan Nishioka <a...@nishioka.com> wrote: > On Jul 15, 8:44 am, austin <aus...@xilinx.com> wrote: > > > > > All, > > > The Parallel III cable was built before we had JTAG that had its Vcco > > lowered to 2.5V, and a whole slew of features added ... > > >http://direct.xilinx.com/bvdocs/userguides/ug332.pdf > > > Figure 9-1, has a good schematic of what is going on: input pins > > require series resistors, as they all use 2.5 V as their internal Vdd, > > output is optionally able to pullup (to Vccaux), see XAPP453. Also note > > Table 2-9 in the above referenced document, specifically what the TMSPIN > > does (enables, disables pullup to Vccaux internally). > > > So, may an older parallel III cable work?: yes, but, you need to have > > the series resistors on input, and you need to address the TDO output, > > by either setting the TMSPIN to the right state, or providing an > > external pullup on TDO. > > > The newer cables are 'smart' enough to figure out what to do, even > > though there may be settings that are enabling/disabling pullups. > > > Austin > > So are you saying the parallel cable III output is 3.3V? > > I thought it had a CMOS buffer inside, powered by the red vcc line > (2.5V in my case). Also it has 100ohm series resistors and a TDO > pullup. > > I finally found a schematichttp://www.xilinx.com/support/programr/files/0380507.pdf > > Alan Nishioka I hooked my parallel-3's vcc to 3.3v so it's output would be high enough for my pc to read. Then i put 100ohm resistors on all the lines to the fpga. Xilinx only says 68 ohms are necessary as per the document suggested by austin. I've had good luck with my parallel-3. I think the key is using 74hc parts. Next is having a computer that happens to have low thresholds :-)Article: 121938
Pasacco wrote: > ".prj file" contains "library creation and mapping". > Thank you for comment. > > I see following statements in the ".prj" file for one module. > ------------------------------------------------------------------- > -- Generated by GUI > > vhdl submodulelib "../../src/submdule_pkg.p.vhdl" > vhdl submodulelib "../../src/submdule.e.vhdl" > vhdl submodulelib "../../src/submdule_rtl.a.vhdl" > ...... > ------------------------------------------------------------------- > > Suddenly, I am confused. > Let me ask question. > > ".prj file" does not look like a script. > > Suppose we have the ".prj file", > In order to actually "create and map libraries", what is next step to > proceed? > Well, it's not exactly a script but in this text file you have the mapping ... maybe you can try modify them there ... I don't use the GUI and just the command line, and when I want to map something to a library I modify the prj file (you can modify it with a perl script if you have lots of thing to change). SylvainArticle: 121939
Alan, The 74hc125 is powered from the connections... or is it? VDD is not VCC, and connection to pin 14 is not shown... Again, the 2.5 V inputs on 3SE will clamp a 3.3V output (to one diode drop above 2.5V), and you should know what the TDO is set to do (pullup, or not). Lots of people have problems with the older cables, and the newer parts. There is the issues I mentioned, and then there is cable length (from some to a lot), as well as how the pcb was wired to the JTAG header. I have seen cases where there was a LED directly on some wires to ground, or to Vcc(?). These LED's 'worked" for old parts, but clearly made the interface not work at all on the newer 2.5V parts. Last but not least, we have seen issues with the green wire safety ground for the computer, with 3V of AC, making the interface really confused. Can't happen on a laptop, however (if it isn't plugged into the wall). Just relaying what I see.... AustinArticle: 121940
"Ben Twijnstra" <ben.twijnstra@gmail.com> wrote > Marc Battyani wrote: > >> I've just got a brand new board with a Stratix II S180 on it. Before I >> power it on, I checked the power supply rails for short-circuits. I get >> 20 >> ohms on the 1.8V supply rail and 1.2 Ohms for the 1.2V. 20 ohms does not >> look like a short but 1.2 is rather small. On those supplies, I only have >> logic components and decap capacitors, the power supply is on another >> board. >> >> So any advice before I push a few amps in it? Short or not? >> (I must say that I'm somewhat stressed by the device price ;-) > > Marc, > > 1.2 Ohms is fairly normal for this device. The EP2S90 is about 2 Ohms. You > should get worried if it goes below 1 Ohm. Had one customer see 0.2 Ohm - > turned out to be a short beween VCCint and PLL ground. Thanks Ben, In fact I did found shorts on another board (cf link below). They were all between pads of the LLM21 decoupling caps and around 0.2-0.3 ohms. BTW I'm somewhat upset with this, considering that I got the boards inspected visually and by x-rays at the assembly shop. :( http://www.fractalconcept.com/short-pb1.jpg MarcArticle: 121941
Cla wrote: > My company may soon have to put together our first embedded system. > Since we're beginners, we're probably not going to (a) know what we're > doing, > (b) have a good firm set of application requirements, (c) have a lot of > embedded/programming experience. > > The target hardware would most likely be one of the Tensilica 32-bit > cores, or an ARM/922 (probably not an ARM7 TDMI.) > > I realize that makes this question really really loaded, but given the > criteria > of "needs to be maintainable by non linux-gurus", what's the better > embedded O/S choices? Can be commercial or open-source...since we're > willing to pay a little more upfront for (hopefully) eaiser learning curve. I haven't looked too deeply into the Nucleus OS but they're on the top of my list to evaluate for an embedded Mico32 processor application. The numbers I saw for them 2-3 years ago was pretty impressive with respect to kernel size and configurability.Article: 121942
Hi All, I am new to Quartus II, and am trying to run a functional simulation. I am using the "Vector Waveform Editor" and put in input nodes and some of the output nodes that I want to see. However, when I run the functional simulation, I do not see the waveforms for some of the input/output nodes. The warnings say: "Can't find node <X> for functional simulation. Ignored vector source file node." The warning for the inputs is: "Can't find signal in vector source file for input pin <X>." How do I fix this error? Thanks in advance.Article: 121943
On Jul 15, 10:23 am, christophe ALEXANDRE <christophe.alexan...@gmail.com> wrote: > XC4000 was not supported by XST, that's true but it was still supported > by Express and worked perfectly. What is the problem ??? have your HD crash, and ask Xilinx for another key for your license so you can reinstall on the new drive ... you cann't get one.Article: 121944
Well, so we now have reduced the flaming merciless attacks on Xilinx to something much simpler: the problem of obtaining new software, after you failed to back up your computer properly. What a "tempest in a tea pot", as the British say. Maybe something can be done about this... Peter Alfke, from home On Jul 15, 8:30 pm, Totally_Lost <air_b...@yahoo.com> wrote: > On Jul 15, 10:23 am, christophe ALEXANDRE> > <christophe.alexan...@gmail.com> wrote: > > XC4000 was not supported by XST, that's true but it was still supported > > by Express and worked perfectly. What is the problem ??? > > have your HD crash, and ask Xilinx for another key for your license so > you can reinstall on the new drive ... you cann't get one.Article: 121945
Austin, thank you very much for your detailed answer! It became quite clear for me now. Just one more question: How do I practically generate the forwarded clocks? Just a toggling 1-bit signal (1..0..1..0..)? Do I have to use dedicated clock I/Os? I think so...!? Regards, GeroArticle: 121946
Kiran wrote: > Hi All, > I am new to Quartus II, and am trying to run a functional > simulation. I am using the "Vector Waveform Editor" and put in input > nodes and some of the output nodes that I want to see. However, when > I run the functional simulation, I do not see the waveforms for some > of the input/output nodes. The warnings say: "Can't find node <X> for > functional simulation. Ignored vector source file node." The warning > for the inputs is: "Can't find signal in vector source file for input > pin <X>." > > How do I fix this error? Thanks in advance. Hi Kiran, This warning occurs when after synthesis, the node you intend to see is buried inside a logic element or is optimized away completely. The best thing to do is to go to the Assignment Organizer (Ctrl+Shift+A) and do the following: In the "To" field, add the name of the node that disappeared in the simulation. In the "Assignment Name" field, choose the "Implement as output of logic cell", and in the "Value" field, choose "On". Do this for all the nodes that disappeared (buses and wildcards are OK when entering the assignment) an you should be OK. PS: Have a look at http://www.niosforum.com/forum - It's a specialized forum for Altera users, and lots of people from Altera themselves are posting answers and suggestions there. Best regards, BenArticle: 121947
Hello, I'm trying to simulate my design in modelsim and i'm trying to find out if it is possible to choose the set_up delays of the clock signals in a simulation. Indeed in my simulation the clock edge are too fast (0 ns) so it creates errors in my simulation which will not appears in a real design due to set_up delays. I'm trying to use ' vsim -sdf' function but it don't seems to works. Thancks in advance for answering.Article: 121948
Thanks very much I have another question: I build my main in C code and I want to call a function in ASM. In my C code, I put this: extern int Add(int a, int b); In my ASM: Add: #code But when I compile, I have that error message: undefined reference to `Add' To my mind, I miss something in the prologue of my assembly code. That's right ?Article: 121949
On 2007-07-15, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > 80,413 NONZERO BYTES > > >============== SORTED ================= > > NNN Byte Hex Frequency > > 0 0 0 181,476 2/3 of the data is empty of bits > 1 255 FF 5,809 all bits set is next most common. > 2 1 1 5,390 > 3 128 80 3,991 > 4 4 4 3,867 > 5 8 8 3,815 > 6 16 10 3,785 > 7 32 20 3,653 > 8 2 2 3,364 > 9 48 30 3,282 > 10 64 40 3,139 followed by one bit set. > 11 12 C 1,941 > 12 3 3 1,587 > 13 192 C0 1,472 > 14 36 24 1,038 and two bits set.... are there any longer repeating patterns or is the data pretty random byte by byte
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