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
Does Xilinx plan to use the single transistor SRAM? See <www.mosysinc.com> for more info about it.Article: 29726
Andy, ----- Original Message ----- > > I will probably shock someone somewhere, but I agree with you. There > > are some things that are so well entrenched, so ubiquitous, and/or so > > screwey to implement (perhaps intentionally), that FPGA's are not > > even a realistic consideration. The ASIC is just too cheap and easy > > not to use. this is true for most cases (so does not shock me). But the moment you cannot find a chip that is dedicated to your specific application things may look different, audio could be an example here. Assume the TUSB3200 did not exist (or is buggy). You would switch to something different, e.g. an AN2131 (which is truly more expensive). You would add your audio functionality to it, basically shift registers and FIFOs. This is the moment you begin thinking about adding an FPGA to your design. Next you would start to move all your surrounding logic into the FPGA, as this makes better usage of a component that is already on your board. The IEC958 output gives you your first $4, which is already about a third of your Spartan-II. As an 8051 is not too good in moving data around you wish you could interface your audio FIFO directly to the endpoint. So one could imagine using a PDIUSBD12, a little bit more FPGA and a standard 8051- if it only had more endpoints... which brings you to your own USB implementation (as 200/768 slices are only $3.20). And at the same time your product management approaches you to add some fancy level meters. And finally you have a pricing that is very competitive to a solution based on the TUSB3200 again. But you are right- it is not the same lean and mean very low-cost design it was in the beginning. Products are distinguished either by features or by pricing. Sometimes you want a product, that adds a little bit to "what everybody is doing". And here your off-the-shelf ASIC may create a lot of headaches. > Methinks it's a case of "if the only tool available is a hammer, > everything starts to look like a nail." I think there are two different situations here: a) Do I use an FPGA or not? b) Do I add another chip or upgrade to a larger FPGA? And the latter scenario boils down to the following questions: i) Do I have the time to invent Intellectual Property? ii) Can I effort buying Intellectual Property? Best regards Felix Bertram _____ Dipl.-Ing. Felix Bertram Trenz Electronic Duenner Kirchweg 77 D - 32257 Buende Tel.: +49 (0) 5223 41652 Fax.: +49 (0) 5223 48945 Mailto:felix.bertram@trenz-electronic.de http://www.trenz-electronic.deArticle: 29727
> Does Xilinx plan to use the single transistor SRAM? See <www.mosysinc.com> for more info about it. About about checking out the page byself ? The mosys 1T sram is dram with a clever refresh scheme. Nothing that could be used in a FPGA.Article: 29728
In article <neYo6.602$lt4.323371@paloalto-snr1.gtei.net>, chilln@gte.net (Embedded Head) wrote: > Company song, hmmm, yes I can see it now......while they're doing their > ergo > exercises > "Shift to the left, shift to the right" > "Push down, pop up" > "Byte, byte, byte" > > Thanks for the idea, see, you consultants really are smart fellers My fee for suggesting the company song idea is $10,000. How would Sir like to pay? -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 29729
On Mon, 05 Mar 2001 18:06:41 GMT, krw@btv.ibm.com (Keith R. Williams) wrote: >On Mon, 05 Mar 2001 17:31:38 +0000, Brian Drummond ><brian@shapes.demon.co.uk> wrote: > >>On 03 Mar 2001 15:44:07 -0800, Eric Smith >><eric-no-spam-for-me@brouhaha.com> wrote: >> >>>Peter Alfke <palfke@earthlink.net> writes: >>>> The gist is: >>>> Virtex parts do check for CRC errors, but not for formatting errors. And you >>>> sent a legitimately CRC-protected file, just the wrong format... Horrendous >>>> amount of internal contention. >>>[...] >>>> Correct. If there were a CRC error, the part would recognize this. But there >>>> was no CRC error... >>> >>>Is there some reason why the part doesn't ALSO recognize that the bitstream >>>is too short? I wouldn't think it would expect the CRC until it had filled >>>all of the RAM cells. >>> >>Anything to do with partial reconfiguration maybe? >>Like, is it possible to generate a _valid_ short bitstream to reprogram >>part of the device but leaving the remainder unchanged? > >Perhaps you've just stepped on another reason the tools don't support >partial reconfiguration? Two _valid_ short bitstreams may create many >drivers on the same wire. Ouch! The Virtex-II device ID feature can't protect against THAT one! I'm not sure anything can. Except maybe some design rule checker running on the set of placed/routed NCD files prior to bitfile generation. Doesn't look like an easy problem. - BrianArticle: 29730
This is a Senior level position needed. Please send me your resume to be consider for this Senior Level position in an amazing company with good benefits. Senior Engineer ASIC Design Education Required: BS/MS in Electrical or Computer Engineering 3+ years experience Responsibilities: Digital Subsystem/ASIC/FPGA detailed logic design Synthesiable VHDL/Verilog model design Scripts and utilities development Provide sales support Required: Ability to express logic in synthesizable VHDL or verilog Firm understanding of the transformation go RTL code into gates ASIC or FPGA design experience Understanding of high-speed and sub-micron design issues Excellent analytical and communication skills Highly motivated self starter, well organized Solaris or Windows-NT Preferred: BIST Test complier Fault Grading Test generation Firmware / Assembly CMDA / TDMA Digital PLL design Clock tree Design DMA design 1394 802.3 FIFO design Bus interface design Datapump design >100k gates Sub-miron experience FPGA - Xilina or AlteraArticle: 29731
This is a leading position in which you report to the director of Engineering for an up and coming company. You would be the main player and supervisor for this Phoenix based company. Please email me your resume. If you know someone interested in this job please forward it on to the right person. This is an amazing opportunity. Principal Engineer ASIC Design Education: BS/MS in Electrical or Computer Engineering 10+ years experience Responsibilities: Project technical guidance and leadership Digital system architecture development & partitioning HW vs. SW partitioning Digital subsystem/ASIC/FPGA detailed logic design Synthesizable VHDL/Verilog model design Scripts and utilities development Provide sales support Write proposals Manage projects on time and budget schedules Desired Skills: Ability to express logic in synthesizable VHDL or verilog Firm understanding of the transformation of RTL code into gates ASIC or FPGA design experience Project planning and leadership experience Understanding of high-speed and sub-micron design issues Excellent analytical and communication skills Highly motivated self starter, well organized Solaris or Windows-NT Preferred: BIST Test complier Fault Grading Test generation Firmware / Assembly CMDA / TDMA Digital PLL design Clock tree Design DMA design 1394 802.3 FIFO design Bus interface design Datapump design >100k gates Sub-miron experience FPGA - Xilina or Altera Required tool experience Synopses design Complier VHDL simulation (Modelsim, Speedwave) or Verilog simulation (Chronologic, Cadence) Preferred: C++,Perl, TCL/tk, Logic Analyzers,ICE, DSO, Performace Analyers, Viewlog, Mentor GraphicsArticle: 29732
Please dont cry folks ;-) I ran through the preveous thread and have still some questions. We have a hot-swapable card and to prevent big surge currents we have to use a very slow powerup ramp (250ms are planned). Is this a problem for the Spartan II?? The powersupply can delviver far more than 500mA but not that fast as required in the datasheet (50ms). Another question is about the Vcoo and Vcint timing relation. How critical is it (Vcoo must be above 1V when Vcint crosses 1.6V (POR) ). -- MFG FalkArticle: 29733
This is a multi-part message in MIME format. --------------153262FA8A8693E02C0790D6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just wondering.... Thanks all! attn. Juan --------------153262FA8A8693E02C0790D6 Content-Type: text/x-vcard; charset=us-ascii; name="jmrivas.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Juan M. Rivas Content-Disposition: attachment; filename="jmrivas.vcf" begin:vcard n:Rivas;Juan M. tel;home:(617)255-1268 tel;work:(617) 253-5097 x-mozilla-html:FALSE org:Media Lab, M.I.T.;Object Based Media version:2.1 email;internet:jmrivas@media.mit.edu title:Research Assistant adr;quoted-printable:;;20 Ames Street=0D=0A;Cambridge;Massachusetts;02139;U.S.A. fn:Juan M. Rivas end:vcard --------------153262FA8A8693E02C0790D6--Article: 29734
Marc Battyani wrote: > > "Marc Reinert" <reinert@tu-harburg.de> wrote > > > I' like to use a CPLD/FPGA (Xilinx) to receive data from the parallel > > port (EPP-mode) of my PC. > > > > Is it a good style to react direct on the edges of the port signals (e. > > g. adress/data strobes) or would it be better to use a fast PLD-Clock to > > sample the port and then to evaluate the signals in a clocked logic? > > I've done this in a Spartan device. You should synchronize the inputs to an > internal clock and 2 flip-flops. (See the ongoing thread on Metastability). > Then just use a state machine. > > It works well but I coudn't make the EPP going faster than 750Kb/s under W2K > (Dell I5000e PIII 700). We did a Parallel Port CPLD, and found similar speeds. Certainly the std PC mode is limited to about 1uS per transaction, but we found that most EPP/ECP modes were also limited. Mid last year we were told there were true PCI-ECP ( not PCIpatch-ISA-ECP) comming 'real soon' that would offer a more usable speed, of some MegaBytes/Sec Has anyone seen these, or got a better speed spec for PC-parallel IO ? -jgArticle: 29735
Hi, ExperVision uses alogrithms to achieve recognition, and you can try a demo at www.expervision.com Good Luck "Magali Oudard" <Magali.Oudard@ms.alcatel.fr> wrote in message news:3AA4BFEA.28DC200D@ms.alcatel.fr... > Hello everybody, > > my friend has to realize the implementation of an OCR algorithm in > schematics or VHDL, > with fondation or any other FPGA software. > > As a student he is in internship in the USA, and does not have easy > access (beside work) to computer and internet. > > If somebody could give him (us) some clue for him to get started ? > apparently a demo version of software is enough, but here are the > questions : > 1. Where can he download a free demo version of a good software ? > 2. Where can he find a description of an OCR algorithm ? > 3. Where can he find good documentation to program in VHDL ? > > > Thank to evryone ! > > > (more detail description of the subject : > Make under fondation or other software for FPGA a development of > a simulation in schematics or VHDL for the following problem : > OCR algorithm for one character on a matrix, dimensions from > 10*10 to 500*500 points) >Article: 29736
Is there any document that gives more detailed logic drawings of the Spartan II CLBs? The description and diagram in the data sheet are sort of, well, spartan. I'm trying to figure out whether I can do certain things like simultaneously route the carry out both to the carry-in of the CLB above *and* to the GRM or to the CLB on the right. Figure 3 in the data sheet shows a slice, but it has big unexplained blocks like "Carray and Control Logic". Also, the possible routing choices for signals are not obvious. The text talks about the F5 and F6 multipliexers, but they don't appear in the drawing at all. These details aren't considered proprietary trade secrets, are they? That would make it hard for me to figure out how to best design for this part.Article: 29737
You can always look in FPGA editor. Nothing can be left out there. If its routed or routable, its there. Chris Eric Smith wrote: > Is there any document that gives more detailed logic drawings of > the Spartan II CLBs? The description and diagram in the data sheet > are sort of, well, spartan. > > I'm trying to figure out whether I can do certain things like > simultaneously route the carry out both to the carry-in of the CLB above > *and* to the GRM or to the CLB on the right. Figure 3 in the data sheet > shows a slice, but it has big unexplained blocks like "Carray and Control > Logic". Also, the possible routing choices for signals are not obvious. > > The text talks about the F5 and F6 multipliexers, but they don't appear > in the drawing at all. > > These details aren't considered proprietary trade secrets, are they? > That would make it hard for me to figure out how to best design for > this part.Article: 29738
Felix Bertram wrote: > > Andy, > > ----- Original Message ----- > > > I will probably shock someone somewhere, but I agree with you. There > > > are some things that are so well entrenched, so ubiquitous, and/or so > > > screwey to implement (perhaps intentionally), that FPGA's are not > > > even a realistic consideration. The ASIC is just too cheap and easy > > > not to use. > > this is true for most cases (so does not shock me). But the moment you > cannot find a chip that is dedicated to your specific application things may > look different, audio could be an example here. > > Assume the TUSB3200 did not exist (or is buggy). You would switch to > something different, e.g. an AN2131 (which is truly more expensive). You > would add your audio functionality to it, basically shift registers and > FIFOs. This is the moment you begin thinking about adding an FPGA to your > design. Next you would start to move all your surrounding logic into the > FPGA, as this makes better usage of a component that is already on your > board. The IEC958 output gives you your first $4, which is already about a > third of your Spartan-II. As an 8051 is not too good in moving data around > you wish you could interface your audio FIFO directly to the endpoint. So > one could imagine using a PDIUSBD12, a little bit more FPGA and a standard > 8051- if it only had more endpoints... which brings you to your own USB > implementation (as 200/768 slices are only $3.20). And at the same time your > product management approaches you to add some fancy level meters. And > finally you have a pricing that is very competitive to a solution based on > the TUSB3200 again. But you are right- it is not the same lean and mean > very low-cost design it was in the beginning. > > Products are distinguished either by features or by pricing. Sometimes you > want a product, that adds a little bit to "what everybody is doing". And > here your off-the-shelf ASIC may create a lot of headaches. > > > Methinks it's a case of "if the only tool available is a hammer, > > everything starts to look like a nail." > > I think there are two different situations here: > a) Do I use an FPGA or not? > b) Do I add another chip or upgrade to a larger FPGA? > > And the latter scenario boils down to the following questions: > i) Do I have the time to invent Intellectual Property? > ii) Can I effort buying Intellectual Property? Felix, I see your points. In this case, since the TI part *does* exist (I'm still waiting for my eval board, so "bugginess" is TBD), it makes a lot more sense to go with that rather than roll my own into an FPGA. Why? Because it does all of the hard stuff. You mention the audio stuff -- that's what this part does. It has digital audio CODEC ports (and the clock generation!) on board, the audio ports are on endpoints. The only programming required is to set up source and destination for the endpoints. As data comes in from the PC, it's DMAed right out to the audio interface -- no programming or overhead required. If this part didn't exist, I'd use the Philips part, with built-in ADC and DAC. Believe me, I prefer to do FPGA designs. But using this type of part makes a whole lot more sense than trying to implement USB in an FPGA. I have the product concept nailed down, and I think the TUSB3200 is the way to go. -aArticle: 29739
"Timothy R. Sloper" <trs@mpinet.net> wrote in message
news:TZ_o6.473$gF.156955@news2.aus1.giganews.com...
> Simon,
>
> One feature Actel has in their antifuse parts that no SRAM parts have
to
> my knowledge is the ability to look at ANY node in the design during
normal
> system operation. This is done via Silicon Explorer. There is absolutely
no
> need to bring signals out to unused pins. As for the BGA/OTP relationship
> you described (chasing interconnect problems)... does that potential
problem
> not apply to any other technology implemented in a BGA? Xilinx would be as
> difficult, if not more diffcult, to chase down interconnect problems when
> using BGAs than any of the Actel antifuse parts.
>
> Also, the ProASIC (used to be Gatefield) parts are fully functional and
have
> in fact been shipping to select customers for quite some time. The delay
in
> delivery had nothing to do with function... yield has been the issue.
> ProASIC will be hitting distributors very soon (not just marketing BS).
>
> Tim
Tim,
Apart from what Ray Andraka told you above, there is the problem of
OTP/BGA parts being used with sockets. As the designs get bigger
functionally and with more balls, there is a tendacy not to get everything
right the first time. Therefore, one will most likely have to take the part
off the board and replace it before one gets it right. This is a pain in
the rear with BGA parts. If one uses BGA sockets, then one will more likely
have more interconnect problems than with PQFP sockets. If one doesn't have
BGA sockets, then one will have to remove and replace. This can really wear
a board down. My wife removes and replaces BGA parts for a living as part
of her work, and she says that the boards cannot handle too many cycles of
this activity.
I feel is that Actel does have very good silicon, and Actel OTP parts
have their place in this world. But for most designs, I do not feel that
OTP is a good idea. If you don't believe me, then dig up some marketing
data and look at the FPGA market pie in terms of sales dollars or even
number of parts shipping. You will find that OTP parts are a small slice of
that pie. If you have that information, perhaps you can share it with us.
I think that if Actel can get the ProASIC to market and it turns out to
be a good product, you will be a lot busier helping engineers out with that
product than with OTP product.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
Article: 29740
"Embedded Head" <chilln@gte.net> wrote in message
news:neYo6.602$lt4.323371@paloalto-snr1.gtei.net...
> Company song, hmmm, yes I can see it now......while they're doing their
ergo
> exercises
> "Shift to the left, shift to the right"
> "Push down, pop up"
> "Byte, byte, byte"
>
> Thanks for the idea, see, you consultants really are smart fellers
Embedded Head,
Maybe you can adopt the company song called "Bad Company" by Bad
Company. :)
Simon Ramirez, Smart Arss Consultant
Synchronous Design, Inc.
Oviedo, FL USA
Article: 29741All, When using the new Virtex II Internal Configuration Access Port (ICAP), one has to also use the tools properly with the logic floorplanner, nailing down the separate regions, and IO intefaces between the separate regions to be reconfigured. We are on the "cutting edge" of providing the tools, the hardware, and the methodologies, so this certainly isn't a smooth and easy process (yet). The basic features are there (ICAP, floorplanner, etc). There must be first the floor planning, and the identification of reconfigurable regions (some systems architecture must go it first). This is an exciting feature that has the universities all asking the right questions, and hopefully ready to provide some answers to today's problems in reconfigurable computing. Austin Brian Drummond wrote: > On Mon, 05 Mar 2001 18:06:41 GMT, krw@btv.ibm.com (Keith R. Williams) > wrote: > > >On Mon, 05 Mar 2001 17:31:38 +0000, Brian Drummond > ><brian@shapes.demon.co.uk> wrote: > > > >>On 03 Mar 2001 15:44:07 -0800, Eric Smith > >><eric-no-spam-for-me@brouhaha.com> wrote: > >> > >>>Peter Alfke <palfke@earthlink.net> writes: > >>>> The gist is: > >>>> Virtex parts do check for CRC errors, but not for formatting errors. And you > >>>> sent a legitimately CRC-protected file, just the wrong format... Horrendous > >>>> amount of internal contention. > >>>[...] > >>>> Correct. If there were a CRC error, the part would recognize this. But there > >>>> was no CRC error... > >>> > >>>Is there some reason why the part doesn't ALSO recognize that the bitstream > >>>is too short? I wouldn't think it would expect the CRC until it had filled > >>>all of the RAM cells. > >>> > >>Anything to do with partial reconfiguration maybe? > >>Like, is it possible to generate a _valid_ short bitstream to reprogram > >>part of the device but leaving the remainder unchanged? > > > >Perhaps you've just stepped on another reason the tools don't support > >partial reconfiguration? Two _valid_ short bitstreams may create many > >drivers on the same wire. > > Ouch! The Virtex-II device ID feature can't protect against THAT one! > I'm not sure anything can. Except maybe some design rule checker running > on the set of placed/routed NCD files prior to bitfile generation. > Doesn't look like an easy problem. > > - BrianArticle: 29742
Falk, We do not test every single part for any power on ramp exceeding 50 ms. We have done characterization which shows you may have problems with ramps longer than 100 ms because you can not keep the voltage generally increasing through the critical power on trip point (POR). Spartan II has no Vccint vs. Vcco sequence issues (either can be before the other, and outputs remain tristate, and no current results on the Vcco). Virtex E MUST have Vccint before Vcco to operate properly. This is not true of Virtex, or Spartan II. I would work closely with your Xilinx FAE to characterize your application to be sure you will have a reliable design across all corners. We are in the midst of a respecification of Spartan II right now. I have heard: longer ramps, current vs ramp rate, sequence issues, non-linear ramps, and current vs device size all requested. Have I missed anything????? Thank you, Austin Falk Brunner wrote: > Please dont cry folks ;-) > > I ran through the preveous thread and have still some questions. > We have a hot-swapable card and to prevent big surge currents we have to > use a very slow powerup ramp (250ms are planned). > Is this a problem for the Spartan II?? The powersupply can delviver far > more than 500mA but not that fast as required in the datasheet (50ms). > Another question is about the Vcoo and Vcint timing relation. > How critical is it (Vcoo must be above 1V when Vcint crosses 1.6V (POR) > ). > > -- > MFG > FalkArticle: 29743
Juan, Yes. Contact me at austin@xilinx.com. Austin "Juan M. Rivas" wrote: > Just wondering.... > > Thanks all! > > attn. JuanArticle: 29744
In October 1999 at the EXUS in Paris we made Xilinx aware of that self-destruct feature of the Virtex series. A second participant confirmed the phenomenon immediately. Xilinx confirmed it about a week later. Apparently they did not find a workaround. Is anyone aware of a warning issued by Xilinx? Alfred Fuchs Siemens PSE PRO LMS Peter (and Austin and Phil), Here is my take (*please* correct me where I'm mistaken): It sounds like there are two weaknesses in (at least) some of the Xilinx device families that can lead to catastrophic failures: 1. Devices don't check the programming data stream for a "match" of target device. Thus, you can try to program a Virtex 600E device with a Virtex 400E configuration data stream, and the configuration data will be accepted. This "hole" allows the designer to make a mistake, and be burned by it. The workaround is, simply, to make sure that your configuration files were compiled for the correct target device; you screw up at your own peril. 2. More ominous is that drivers for internal multi-source busses are not disabled (tri-stated, if you will) before and during the configuration and powerup sequence, when the internal state of the device cannot be controlled or specified by the designer. I'm not sure there is *any* workaround to this, short of a re-design of the FPGA die. We need to understand the breadth of this problem (if the above assessments are basically correct): which device families are affected (afflicted), etc. etc. I'm not posting this to cause alarm, but to distill the issues at hand as clearly as possible, and avoid any FUD. Rather than get excited, it would be good for all concerned to await Xilinx's response which, if history is a guide, will be an honest and open discussion of the facts, and which will provide essential guidance to the design community. Bob Elkind, eteam@aracnet.comArticle: 29745
How should I use the two FF's to synchronize the strobes?
Here is my idea how it could work:
| |
Data --/---->| Data Reg |---/--------------------> DATA
8 | | 8
CLK -----------^
+------------|&|----------> CE
| |
| |---+--->| | |
Strobe ------>| FF1 | | FF2 | |
| | | |O-+
CLK -------------^--------------^
I'll sample the strobe and data signals with the same clock. The strobe signal
is shifted through two FF's in series.
These two FF's generate the CE (FF1 AND NOT FF2, rising edge) signal for the
outgoing data.
Is this what You mean?
V R wrote:
> I just started a nice long thread on exactly this subject. I think the
> unanimous opinion is to use *two* D-flip-flops hooked in series. For the
> EPP interface, since you have two strobes, you will have two sets of these
> dual flip-flops to synchronize with.
>
> Use a system clock to synchronize your incoming nAddressActive and
> nAddress Strobe through the dual flip-flops(one set of FFs per strobe); it
> helps a lot to use this same clock for your statemachine, so do that if
> possible.
>
> My design had one statemachine (with two states I think) to recognize the
> four-phase portion of the EPP interface, and then other statemachines to
> act on the data.
>
> Good luck!
> VR.
> (the above e-mail address is invalid).
I've no idea what's wrong with my email: reinert@tu-harburg.de
--
Marc
Article: 29746Hi Thirumurgan, I haven't used Foundation series, but your problem seems to be more general. If I understand you well, you have a Verilog netlist (from Webpack) - right? (or EDIF may be). If so the issue of "compatibility" SHOULD not arise as these are STANDARDS (though some tools may not support full standard). When you say "lot of warnings" - can you elaborate on that? What are they? Perhaps it says "module DFF not found" etc.? If so you will need to specify the library file name to Foundation series tool (Check out their documentation). HTH, Srini thirumurugan wrote: > > Sir, > Can netlist generated from Webpack ISE be loaded in Foundation Series 2.1 simulator. Is the netlist compatible. Iam synthesysing VHDL designs in Webpack and when i load the netlist in Foundation series simulator i am getting lot of warnings. should i make any settings in the environment settings.help me please. > thanks in advance,stm. -- Srinivasan Venkataramanan (Srini) ASIC Design Engineer, Chennai (Madras), IndiaArticle: 29747
Hi Balaji,
Balaji Krishnapuram wrote:
>
<SNIP>
>
> I use a library(BITLIB) which came along with my textbook("Digital system
> design using VHDL" by Charles Roth) to define bit, bit_vector etc instead of
> using the IEEE std_logic etc.
>
Strange, why would you need this BITLIB? - are you sure it is to
"define" bit & bit_vector data types? AFAIK they are already defined
in the STANDARD package (in STD library) - which is by default visible
to all VHDL code. Infact if you try defining your own bit, bit_vector
etc. this will cause ambiguity to a VHDL compliant
simulator/synthesis.
So please check the BITLIB package and make sure you are using it
properly.
From a quick look at your code, you have a function "vec2int" which is
probably defined in this BITLIB. Again if you want to learn better
VHDL try using
IEEE.numeric_bit.all
package instead (then use to_integer(bit_vec) function)
HTH,
Srini
> Hope it helps:)
>
> Balaji
>
--
Srinivasan Venkataramanan (Srini)
ASIC Design Engineer,
Chennai (Madras), India
Article: 29748I i used the x-checker with xc9572PC44 and ..it doesn't work well. JTAG is not good! (The IDcode is wrong!) But the xchecker was good with a virtex... I used my home made // cable, and it was the same... Even with a new chip! Can the PC be the cause of this problem? I don't think I have done mistakes on the board, and electric signals are visible on logic analyser... Can someboy help me? thank you.Article: 29749
Juan, There was a post in this newsgroup a few days back, I think P.Alfke from Xilinx was saying that they made hundreds of eval boards with the smallest (xc2v40) virtexII part for their FAE's. Talking to one of these FAE's looks like a good idea! jakab Juan M. Rivas wrote: > Just wondering.... > > > Thanks all! > > attn. Juan >
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