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
No, that is normal. The SpartanII bitstreams are exactly the same as the
original virex bitstreams for the same size device, as are the device codes.
From a user standpoint, the major difference is the missing termperature diode
on the SpartanII and the smaller selection of packaging options.
Grog wrote:
> Greetings all,
> Must be Weird Wednesday today..
> Just got around to stuffing a board with what is supposed to be a SpartanII.
> The writing on the outside says XC2S150 but the JTAG ID is saying XCV150.
> I tried it on two different computers, one 3.3.08i and 'tother' 4.2.03i,
> same result..
> Grabbed an older/different board and it's XC2S150 JTAG ID and Package Label
> are correct. (different batch number)
> So I don't think it's a computer/cable/ISE problem...
>
> Some test code seems to be running ok, the mandatory flashing LED is doing
> the business..
> Verify fails by some 233bits...
>
> Guess I had better have a look at the pin compatability in the PQ208 package
> for these devices.
> Shouldn't I have had smoke by now if it were really the wrong device.??
> (i.e. nothing is hot.... yet..)
>
> I'll write it of as weird shit for now, until next week when a multiplier or
> two just might be handy.. :-)
>
> Anyone had anything similar to this happen to them??
> suggestions welcome.. Is the Spartan II damaged or have we got a tray full
> of "Virti" in disguise.?
>
> Fuzzy Logic at it's best, a big chunk of logic sending my brains fuzzy
> allright.
> Be well,
>
> Greg the Grog
--
--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: 46401Dear Community! Within my Webpack project, I need to include some extern libraries, which i´ve added as VHDL-Modules. It seems that they have to be compiled in a certain order, because one refers to another. I couldn´t figure out in which order Webpack puts the libraries, and in which order it compiles them. (it´s not sorted is it?) Can I set the order as needed somehow? Thank you, ThomasArticle: 46402
Thomas wrote: > Within my Webpack project, I need to include some extern libraries, > which i´ve added as VHDL-Modules. It seems that they have to be compiled > in a certain order, because one refers to another. Yes. You have to start out a VHDL compile with modules with no non-standard external library references and then you have to get the the rest in an acceptable order. You can do this by trial and error or use a makefile generator like modelsim:vmake or emacs:vhdl-make. All the GUIs I've seen ignore the job of sorting the file list (even though this seems like something a computer ought to be able to do:) > I couldn´t figure out in which order Webpack puts the libraries, and in which order it compiles them. > (it´s not sorted is it?) Can I set the order as needed somehow? I don't know how Webpack does it, but if it did it well, you wouldn't be asking the question. -- Mike TreselerArticle: 46403
John_H wrote: > I went looking for information on "StateCad" just now to try and point you to a product with focus explicitly on state machine > design. > > Xilinx bought StateCad! > Awhile ago.... > > I don't know where within my own suite of tools to find the StateCad application, but the redirection from www.statecad.com to > Xilinx.com suggests the application is now part of the Xilinx tools. Maybe you can figure out what remains of StateCad there. > Statecad the program is alive and well, and integrated into iSE. From iSE Project Navigator, simply do Project->New Source, and select "State Diagram". In a second or two you'll be running Statecad. W.r.t the previous question about supported encoding methods for symbolic FSMs, the following are supported by XST synthesis: auto one-hot compact sequential gray johnson user-specified And w.r.t the question about illegal states, I'm not 100% sure I understand the question properly. But consider the following statement from an old copy of the Abel-HDL reference on my desk: "For devices with D-type flip-flops, if none of the stated conditions are met, the state register...is cleared to all 0s on the next clock pulse." -dmArticle: 46404
Hal, since you responded with the only sympathetic answer, let me give you the spec: One Virtex-II BlockRAM can implement: Any state machine with 256 states, each with a four-way branch controlled by two inputs, and with 37 outputs, arbitrarily defined for each state. No hidden constraints or problems. Or: 128 states, each with 8-way branch controlled by 3 inputs, same output flexibility. Or 64 states, each with 16-way branch, controlled by 4 inputs, same output flexibility. No ifs, no buts, no arguments about one-hot vs binary encoding. Recovery from illegal states in one clock period. Runs >150 MHz, conservatively. The concept is archaic, but the practicality is new. "Old" does not necessarily mean bad, I hope. :-) Greetings Peter Alfke, Xilinx ApplicationsArticle: 46405
Grog, You're really up the creek. There is no 208-pin XCV150; they only have 144 and 240-pin leaded QFP devices in the Virtex series. Hmmm.. I wonder what I'm going to find when I get my 208-pin XC2S100E board built? This reminds me of the early TTL days. They would have one die of silicon that they packaged differently for similar functions. In other words, a quad 2-input Nand really had 4 8-input Nands on the die; just "pinned" differently. Get Xilinx to send you 10 new parts for each 1 you return to them just for the inconvenience. This worked for us with another IC company that starts with an A... some 10 years ago. Mark "Grog" <shem_an_na@_SPAMMENOT_hotmail.com> wrote in message news:<1030523817.335887@pluto.global.net.au>... > Greetings all, > Must be Weird Wednesday today.. > Just got around to stuffing a board with what is supposed to be a SpartanII. > The writing on the outside says XC2S150 but the JTAG ID is saying XCV150. > I tried it on two different computers, one 3.3.08i and 'tother' 4.2.03i, > same result.. > Grabbed an older/different board and it's XC2S150 JTAG ID and Package Label > are correct. (different batch number) > So I don't think it's a computer/cable/ISE problem... > > Some test code seems to be running ok, the mandatory flashing LED is doing > the business.. > Verify fails by some 233bits... > > Guess I had better have a look at the pin compatability in the PQ208 package > for these devices. > Shouldn't I have had smoke by now if it were really the wrong device.?? > (i.e. nothing is hot.... yet..) > > I'll write it of as weird shit for now, until next week when a multiplier or > two just might be handy.. :-) > > Anyone had anything similar to this happen to them?? > suggestions welcome.. Is the Spartan II damaged or have we got a tray full > of "Virti" in disguise.? > > Fuzzy Logic at it's best, a big chunk of logic sending my brains fuzzy > allright. > Be well, > > Greg the GrogArticle: 46406
I've been attempting to determine just where those flops are myself. In my case the 20% speed-up is an absolute necessity on a 6000 -4 part I have, but not required on a -5 1000 part I also have. The -5 part non-pipelined multipliers are actually the same speed as the -4 pipelined mults. Latency is not an issue for me, so I am attempting to determine why I shouldn't always use the faster piplined multipliers no matter what the speed grade. However, if the flops are external, I won't have the resources on the smaller part. Also, what is this I have seen concerning an "enhanced" multiplier? -JasonArticle: 46407
In article <2f6f0882.0208280930.6199bc6b@posting.google.com>, Mark Momcilovich <momcilma@yahoo.com> wrote: >Grog, > You're really up the creek. There is no 208-pin XCV150; they only >have 144 and 240-pin leaded QFP devices in the Virtex series. Hmmm.. >I wonder what I'm going to find when I get my 208-pin XC2S100E board >built? It will say it is an XC2S100E, 208 pin, probably, since the Spartain 2Es are not bitfile compatable with the Virtex 2Es or the Spartain 2s. > This reminds me of the early TTL days. They would have one die of >silicon that they packaged differently for similar functions. In >other words, a quad 2-input Nand really had 4 8-input Nands on the >die; just "pinned" differently. Xilinx does that, and has for years. Why would you do different silicon for different pinouts? However, if you are REALLY desparate for flip flops, you used to be able to use the flops in the unused IO pads. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 46408
Dennis McCrohan wrote: > W.r.t the previous question about supported encoding methods for symbolic FSMs, the following are supported by XST synthesis: > > auto > one-hot > compact > sequential > gray > johnson > user-specified > > And w.r.t the question about illegal states, I'm not 100% sure I understand the > question properly. But consider the following > statement from an old copy of the Abel-HDL reference on my desk: > > "For devices with D-type flip-flops, if none of the stated conditions are met, > the state register...is cleared to all 0s on the > next clock pulse." Yes, this is correct - but considering sparse-state machines, and all the enumeration value shuffling implied above, I was wondering if the SW designers were carefull to always include this recovery state in their state maps. .T registers can also sometimes produce more efficent FSM's, but they need special care on the illegal state instance - unlike .D, there is no implicit 'all zero' recovery state. -jgArticle: 46409
Dennis McCrohan <mccrohan@xilinx.com> wrote in message news:<3D6BBC15.75DC16B0@xilinx.com>... > Sounds like you are using symbolic state machines in Abel. Until very recently, these always encoded as one-hot, which is not > usually optimal in a CPLD (unlike a FPGA). > Exactly, but way do you say are optimal in a FPGA? Narcís NadalArticle: 46410
All the questions are for the VHDL core V2.0. 1) In the testbench provided with the code, after the first write command there is a read command after 7th clock cycles. If the read command is given at the 9th clock cycle the simulation breaks down and the DDR controller is stuck in WRITE_WAIT state. I have tried PRECHARGE command after the write command, didnt work, DDR controller was still stuck in the WRITE_WAIT state. 2) How does one enable read/write with autoprecharge? Appnote mentions it can be done but not how. 3) When can we issue a new read/write command? 4) The memory model instantiated in the test bench is MT46V4M32 from Micron. The memory model was not supplied with the code. The RAM model from the Micron website contains 1 DQs (strobe line) line where as the test bench expects 4 DQs lines. The Micron model precharges all banks if line A8 is high. While the core asserts line A10. Has anybody been able to get the core to work? I have tried the older version which was meant for Virtex E devices. I have been able to successfully use that core on a development board but it breaks down when clock frequency is more than 64MHz. Anybody else having the same results? Thanks BrijeshArticle: 46411
This appears to work for the PC based ISE but not the Unix ISE. I'll try downloading the Webpack later to see if it's worth an ad-hoc approach for the state machine potential. Dennis McCrohan wrote: > Statecad the program is alive and well, and integrated into iSE. From iSE Project Navigator, simply do Project->New Source, and > select "State Diagram". In a second or two you'll be running Statecad.Article: 46412
Narcís Nadal wrote: > Until very recently, these always encoded as one-hot, which is not > > usually optimal in a CPLD (unlike a FPGA). > > > > Exactly, but way do you say are optimal in a FPGA? > CPLDs have few flip-flops but wide combinatorial inputs, therefore implement best encoded state machines. FPGA have very many flip-flops, but are limited with wide combinatorial inputs, therefore best implement one-hot state machines, wasteful in flip-flops, but less wide-input logic. Peter Alfke, XilinxArticle: 46413
Hello bit-twiddlers, I was designing what I though to be a simple state machine, with separate synchronous and combinational logic (and processes for each a la "language templates"). 5 legal states, plus a catch for illegal situations, using sequential encoding. I ran into this problem when synthesizing for a virtex-e part using whatever version of WebPack was available about 3 weeks ago -- the state machine appeared to be stuck in an illegal state even though I had placed logic there to prevent this. A clock divider elsewhere in the design (no dependance on the state machine) functioned perfectly. Here's the odd bit.. when I use pins to examine the state registers (i.e. creating ouput pins in the top level entity and assigning the state registers to them) the design works. After examining the synthesis reports, I found that tool had inferred a 3-bit register for the state machine when the state registers were pulled to a pin and a 5-bit register when they were purely internal. This leads me to believe that the webpack synthesis tried to turn my sequential encoding into one-hot encoding, but somehow futzed with the state transitions. I reran the synthesis with as many of the options as I could unchecked in Webpack, but could not get it to give me 3-bit state register. (or a 5-bit one that functioned) Finally, I threw in the towel, and rewrote my state machine one-hot encoded, and it works great. So despite the happy ending, I'm curious as heck if anyone else has had similar experiences/ workarounds to this problem-- I'd like to be able to code state machines how I desire, without using dummy I/O pins. --Josh ModelArticle: 46414
Josh Model wrote: > > Hello bit-twiddlers, > > I was designing what I though to be a simple state machine, with separate > synchronous and combinational logic (and processes for each a la "language > templates"). 5 legal states, plus a catch for illegal situations, using > sequential encoding. I ran into this problem when synthesizing for a > virtex-e part using whatever version of WebPack was available about 3 weeks > ago > -- the state machine appeared to be stuck in an illegal state even though I > had placed logic there to prevent this. A clock divider elsewhere in the > design (no dependance on the state machine) functioned perfectly. > > Here's the odd bit.. when I use pins to examine the state registers (i.e. > creating ouput pins in the top level entity and assigning the state > registers to them) the design works. > > After examining the synthesis reports, I found that tool had inferred a > 3-bit register for the state machine when the state registers were pulled to > a pin and a 5-bit register when they were purely internal. This leads me to > believe that the webpack synthesis tried to turn my sequential encoding into > one-hot encoding, but somehow futzed with the state transitions. I reran > the synthesis with as many of the options as I could unchecked in Webpack, > but could not get it to give me 3-bit state register. (or a 5-bit one that > functioned) > > Finally, I threw in the towel, and rewrote my state machine one-hot encoded, > and it works great. > > So despite the happy ending, I'm curious as heck if anyone else has had > similar experiences/ workarounds to this problem-- I'd like to be able to > code state machines how I desire, without using dummy I/O pins. Interesting - see my comment in the other thread "Any FSM optimizer?" ( below ) You could look at the logic auto-created for the One-Hot, and compare it with yours ? Post it here if you want... > Jim Granville wrote: > > > > Dennis McCrohan wrote: > > W.r.t the previous question about supported encoding methods for > > symbolic FSMs, the following are supported by XST synthesis: > > > auto > > one-hot > > compact > > sequential > > gray > > johnson > > user-specified Did you try any/all of these settings - 'unchecked' is likely to choose Auto :( Compact sounds like it should do a binary model ? <snip> > > > "For devices with D-type flip-flops, if none of the stated conditions are met, > > > the state register...is cleared to all 0s on the > > > next clock pulse." > > > > Yes, this is correct - but considering sparse-state machines, and > > all the enumeration value shuffling implied above, I was wondering > > if the SW designers were carefull to always include this recovery > > state in their state maps. > > .T registers can also sometimes produce more efficent FSM's, but they > > need special care on the illegal state instance - unlike .D, there is > > no implicit 'all zero' recovery state. > > > > -jg -jgArticle: 46415
"Josh Model" <model@ll.mit.edu> schrieb im Newsbeitrag news:Igab9.52$I7.4405@llslave.llan.ll.mit.edu... > Hello bit-twiddlers, > > I was designing what I though to be a simple state machine, with separate > synchronous and combinational logic (and processes for each a la "language > templates"). 5 legal states, plus a catch for illegal situations, using > sequential encoding. I ran into this problem when synthesizing for a > virtex-e part using whatever version of WebPack was available about 3 weeks > ago > -- the state machine appeared to be stuck in an illegal state even though I > had placed logic there to prevent this. A clock divider elsewhere in the > design (no dependance on the state machine) functioned perfectly. > > Here's the odd bit.. when I use pins to examine the state registers (i.e. > creating ouput pins in the top level entity and assigning the state > registers to them) the design works. > > After examining the synthesis reports, I found that tool had inferred a > 3-bit register for the state machine when the state registers were pulled to > a pin and a 5-bit register when they were purely internal. This leads me to > believe that the webpack synthesis tried to turn my sequential encoding into > one-hot encoding, but somehow futzed with the state transitions. I reran > the synthesis with as many of the options as I could unchecked in Webpack, > but could not get it to give me 3-bit state register. (or a 5-bit one that > functioned) > > Finally, I threw in the towel, and rewrote my state machine one-hot encoded, > and it works great. > > So despite the happy ending, I'm curious as heck if anyone else has had > similar experiences/ workarounds to this problem-- I'd like to be able to > code state machines how I desire, without using dummy I/O pins. > Hello Josh, have you thought about the quality of your clock signal. I had a similar problem two months ago with Spartan2E. See my old thread copied below. Previous post from myself. "Helmut Sennewald" <HelmutSennewald@t-online.de> schrieb im Newsbeitrag news:agct89$uvh$05$1@news.t-online.com... > Hello, > we had a problem with the clockbuffer in a Spartan-XCS40XL. > The state machines sometimes went crazy. It is a one hot design. > By accident, we fixed the problem by changing the clock buffer > from the left upper corner to the right lower corner of the chip. > We have used only one clocknet with 20Mhz for all flipflops. > > Now we have transferred the design from XL to Spartan-2E. The > state machines again behave sometimes crazy. > I guess we have 1000 or more flipflops on that clock net. > The power supply voltages are ok. ... > Any idea what is going wrong? > Hello to all readers, the reason for the bad behaviour was the slow rise and fall time of our clock signal. I had used a RC-Filter in the clock line to reduce possible EMI(electro magnetic interference). The time constant including load capacitance was about 10ns. After removing the filter, the FPGA has been working perfectly. Hopefully my answer will help others to avoid that mistake. Best Regards HelmutArticle: 46416
Josh Model wrote: > So despite the happy ending, I'm curious as heck if anyone else has had > similar experiences/ workarounds to this problem-- I'd like to be able to > code state machines how I desire, without using dummy I/O pins. Post your code. It could be missing reset logic or it could be a missing "when others =>" clause to specify a transition out of unexpected state values. -- Mike TreselerArticle: 46417
hi,
I am using Spartan 2E XC2S50E in my design. Configuring the FPGA is
done by using Serial Slave Mode. However, for some reasons when I powered
up the device, I saw a 3Mhz clk signal on the CCLK pin. I don't have 3M hz
clk running on my board and I actually lifted up the CCLK pin so the 3Mhz
clk signal is generated by the FPGA itself.
However, when I started loading the FPGA (Asserting Program Bar), the 3
Mhz clk signal goes away and the FPGA is loaded successfully.
My concern is in the Spartan 2E datasheet, it specified that CCLK pin is
the input but it actually acts like an output when the FPGA is powered up.
I have my MCU's output connected to the CCLK pin and it causes
signal-contention before the FPGA is loaded.
Does anyone have that experience?
Thanks
Jim
Article: 46418http://www.eetimes.com/story/OEG20020826S0029Article: 46419
Does that mean that SpartanIII is a VirtexII? - ds "Grog" <shem_an_na@_SPAMMENOT_hotmail.com> wrote in message news:1030523817.335887@pluto.global.net.au... > Greetings all, > Must be Weird Wednesday today.. > Just got around to stuffing a board with what is supposed to be a SpartanII. > The writing on the outside says XC2S150 but the JTAG ID is saying XCV150. > I tried it on two different computers, one 3.3.08i and 'tother' 4.2.03i, > same result.. > Grabbed an older/different board and it's XC2S150 JTAG ID and Package Label > are correct. (different batch number) > So I don't think it's a computer/cable/ISE problem... > > Some test code seems to be running ok, the mandatory flashing LED is doing > the business.. > Verify fails by some 233bits... > > Guess I had better have a look at the pin compatability in the PQ208 package > for these devices. > Shouldn't I have had smoke by now if it were really the wrong device.?? > (i.e. nothing is hot.... yet..) > > I'll write it of as weird shit for now, until next week when a multiplier or > two just might be handy.. :-) > > Anyone had anything similar to this happen to them?? > suggestions welcome.. Is the Spartan II damaged or have we got a tray full > of "Virti" in disguise.? > > Fuzzy Logic at it's best, a big chunk of logic sending my brains fuzzy > allright. > Be well, > > Greg the Grog > >Article: 46420
edaudio2000@yahoo.co.uk (ted) wrote in message news:<c54bf83f.0208271036.3900471e@posting.google.com>... > Horst Trattnig <9714trho@edu.fh-kaernten.ac.at> wrote in message news:<3D6B4B78.3000500@edu.fh-kaernten.ac.at>... > > Hi Ted, > > > > Well, I use Quartus II since about 8 month and it works fine. If you use > > Quartus II, do'nt use it to compile your VHDL or Verilog File. Use > > Alteras Leonardo OEM , it's free to get at www.altera.com > > > > Your Problem could be based on the Pin Assignment. If you have not done, > > Quartus could not finish your compilation. > > > > If this does'nt works send me a test design and I'll compile it and send > > you the result. > > > > regards, > > Horst > > > Thanks Horst, > But I think the problem has nothing to do with the source files, as I > get exactly the same error no matter what file or design I use as > source, even a > one line do-nothing file. I am also setting the pins to automatic, or > even make my own selection, same results. > > I should say, the software is Quartus II V2.1 Web (the latest version) > from the CD disk I just received. I understand there is a patch file, > but it > only applies to the pay-up version. > > Any ideas anybody? Hi Ted, The license file that Quartus II 2.1 is different from Quartus II 2.0. If you want to use Version 2.1 , you should buy the software. Or you can try to find the crack file for Version 2.1. I use Quartus II 2.1 at present. I also update it from Quartus II 2.0. But I pay it.Article: 46421
Hi all, I have a design which was synthesized, implemented till PAR. I want to get a dynamic power dissipation for the module. I know the Frequqncy of operation for my design. But I need to the determine the capacitances for the input and ouput pins of the design. I am using the Virtex xcv10006-cg560 for implementing my design. What should be a good capacitance approximation on this device. Secondly if there is easy to follow link on xpower , please do mail me the link Thanks PramodArticle: 46422
I am synthesizing a behavioural SystemC design specification with Cocentric SystemC Compiler for an FPGA implementation ( Virtex V800BG432). When just setting : "set_fpga -target VIRTEX -device V800BG432 -speed -4" in the dc_shell script I get a message about the target library who is not defined. What are the settings for the target_library, synthetic_library and link_library variables in .synopsys_dc.setup or in the script file? CharlesArticle: 46423
Hi, You'll need to get ISE at this moment. The next version of webpack (5.1) will support the smallest Virtex II Pro device (the one withouth a powerPC). --- Is there a version of WebPack that supports any of the newer Virtex2 Pro devices? Or do I need to get ISE? Thanks for any replies. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 46424
> Hi Ted, > > The license file that Quartus II 2.1 is different from Quartus II 2.0. > If you want to use Version 2.1 , you should buy the software. Or you > can try to find the crack file for Version 2.1. > > I use Quartus II 2.1 at present. I also update it from Quartus II 2.0. > But I pay it. Thanks Dennis, The software I am using is Quartus II 2.1 "WEB" edition. This is a free IDE similar to the full 2.1 product but with fewer devices supported. The software is available free from Altera on a CD or downloable from their website. The only thing you need to do is to email Altera with your details and they will email you a free licence number. Regards
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