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
Is anyone using VHDL for Spartan XL's? I'm using the WebPack for a Spartan-II, but it doesn't support the XL and was wondering what people use for that series of part (Spartan/XL/4000/etc.). I am inquiring with Xilinx, and haven't received a definite answer yet, but it sounds like Alliance + third party software. It's rather shocking if that is the case that it is free/cheap to develop for newer parts yet very expensive to develop for older parts. I should have shelled out the extra bucks to get Foundation Express with my 1.5 version of Foundation 3 years ago!?!?! argh. JamesArticle: 41101
If you are using Undertow, you will not have to buy another tool like Compare Scan just to compare your waveform files. You have with Undertow three different ways to allow you to compare files. Note that these files can be of any format, wlf, vcd, compressed, any format that Undertow can read, and this tool can read almost every single format from every commercial simulator on the market today. You can compare files even if they have completely different formats. Using Test Analyzer, a tool on Undertow, you can compare two different files, with the differences showing up on the waveform window as a plumb colored back ground over the area of the signal that is different. You can specify the start and end time for the compare, the signals to be compared and a clock with a window on the trailing or leading edge of this clock for this comparison. Using the "Overlay feature" you can overlay three separate files. The resulting waveform will be orange if the signal area is the same, and yellow where they are different. Using the built in Perl scripting tool, and then the compare_file.script which is one of the many several dozen scripts that come with Undertow. With this script, you can do a compare as a batch or interactive process. On very large designs this script can be run without a GUI in a batch process, against files that may be many gigabytes in size. These scripts have been designed to work at very high speeds, hundreds of thousands of times faster than just plane generic Perl. Since the Perl script source code is included in the Undertow distribution, you can quickly modify this code in any way you wish to change the behavior of the exact compare operation. For example, you can allow jitter for a set of signals, or allow a difference threshold before indicating a mismatch, etc. Every single possible compare operation that you can do manually, you can do using this built in Perl scripting capability. You can get Undertow from www.veritools-web.com, and send a request to schop@veritools.com, in order to get a no cost license to use this software. Regards, Robert Schopmeyer/Veritools, Inc. Petter Gustad <newsmailcomp1@gustad.com> wrote in message news:<87it7s1mq1.fsf@filestore.home.gustad.com>... > Petter Gustad <newsmailcomp1@gustad.com> writes: > > > Design Acceleration (now part of Cadence) has a product called > > comparescan for this purpose. > > Comparing waveforms that is, not instantiating the two DUTs. > > With signalscan (waveform viewer) you can easily open two TRN (trace > files generated by the signalscan PLI routines or converted from VCD) > from two different simulations. You can also specify an event search > to find where they differ. > > PetterArticle: 41102
How possible is it? Well if you're a new HDL guy then it's very possible, and if you're not, then its still possible. You should be able to run the same test bench on RTL or gates and have them both pass. "Kelvin Hsu" <qijun@okigrp.com.sg> wrote in message news:<3c97f13b@news.starhub.net.sg>... > Hi, > > I am using Spartan-II chip, I want to know how much possibility that > the RTL and gate-level simulation don't match? > When they don't match, how can I detect that? It seemed that the synthesis > report in ISE 4.1 doesn't give me a warning or error?Article: 41103
Huh? Isn't fixed point implicit in the HDL? What operations are you looking for? magz@citiz.net (Jacke) wrote in message news:<4f071e35.0203191744.1bfd4668@posting.google.com>... > Hi, > Do you know where I can find the open source code of Fixed Point Math Library? > > thanks, :-)Article: 41104
If you have a system that experiences a short-term loss of frequency lock, you will shift the center point of your FIFO. If the clock recovery mechanism switches from a phase error correction mechanism to a frequency error correction mechanism, you will inject or extract a fixed amount of data until the system regains phase lock. Phase locked loops maintain *phase lock* with input jitter levels that are hundreds of unit intervals in deviation. The frequencies during these slews can be off by large amounts - at the low deviation, high frequency end, the slews can be several percent off. These systems maintain phase lock typically by generating the phase error from divided values of the VCO and reference frequencies such that a +/- 180 degree phase slip at the comparator corresponds to +/- M/2 clock cycles for the VCO or +/- N/2 clock cycles in the reference for an M/N divider. Do you contend that a system which tolerates a loss of phase lock and starts the slip required (in typical PLL system's frequency error loops) to reachieve the frequency lock will perform to design with a finite FIFO? If the FIFO fill level is used for feedback in the clock recovery, it is still a phase error that's being fed to the control loops. Only if you consider "phase lock" to be guaranteed phase alignment of less than one clock period, than my terminology fails. If you deal with PLL systems with phase error and frequency error loops (almost all PLLs I've seen), you will have problems if you switch loops. - John_H Peter Alfke wrote: > John_H wrote: > > > The terminology is a bit loose, perhaps. ... > > > The clocks need to be phase locked, > > but can deviate by (significantly) more than one clock period with an appropriately > > sized FIFO. > > That's a self-contradicting sentence! Peter > > John, I do not like "loose terminology". > The FIFO does NOT require phase lock, not even short-term frequency lock. It fixes all > that. > But it can cover up for a frequency deviation only for a limited time, then it either > misses one character or has to "invent" a character. > > You may mean the same thing, but that's not what you said (wrote). > > Peter AlfkeArticle: 41105
sure it's possible since i need to match the result with a C program, while i tried best to match the C result, gate level simulation is not correct. One constraint is that after I finished RTL and everything, I still don't know what problem the design was intended to solve...faint! While RTL simulation and synthesis all pass, w/o major error or warning...i am experienced HDL designer anyway...prob is gate-level won't pass. I want to know how can I detect fatal bugs in my code, besides RTL simu and warning in ISE 4.1? "Jay" <kayrock66@yahoo.com> wrote in message news:d049f91b.0203201704.55c58ac8@posting.google.com... > How possible is it? Well if you're a new HDL guy then it's very > possible, and if you're not, then its still possible. You should be > able to run the same test bench on RTL or gates and have them both > pass. > > "Kelvin Hsu" <qijun@okigrp.com.sg> wrote in message news:<3c97f13b@news.starhub.net.sg>... > > Hi, > > > > I am using Spartan-II chip, I want to know how much possibility that > > the RTL and gate-level simulation don't match? > > When they don't match, how can I detect that? It seemed that the synthesis > > report in ISE 4.1 doesn't give me a warning or error?Article: 41106
Austin Lesea wrote: > > Emanual, > > Why do you need any pullup at all? the als641 is an open collector ? And, I remember reading sowething that I shouldn't use the internal pullups for that purpose. But I could be mixing up something. I have to read it again I guess ;-) > If the 74ALS powered from 5Vdc pulls to less than 3.3 Vdc for the high, so > no series resistor to/from the Spartan IIE is required (simulated the IBIS > models for the 74ALS outputs at 5Vdc driving high into a Spartan IIE). Great ! Save me a lot of troubles here ... > Sounds like the right IOB standard, and just connecting things up is the > right way to go. > Austin Cheers & thanks again. > emanuel stiebler wrote: > > > Hi, > > > > I hope a little problem. > > Trying to connect a 74als641 to a spartan 2e i/o pin. > > And, it is bidirectional ... > > > > My idea is something like: > > > > (74als641 OC) -- (4k7 pullup to 3.3V) -- (100 Ohm resistor in series) -- > > (fpga pin) > > > > Does it work this way ? Any better ideas ? > > > > And if it is of any help, there are around 50-60 pins I have to use this > > way ... > > > > cheers & thanks in advance, > > emanuelArticle: 41107
Tried slowing down the test-bench "clock"? Kelvin Hsu wrote > sure it's possible since i need to match the result with a C program, while > i tried best > to match the C result, gate level simulation is not correct. One constraint > is that after I > finished RTL and everything, I still don't know what problem the design was > intended to > solve...faint! > While RTL simulation and synthesis all pass, w/o major error or warning...i > am experienced > HDL designer anyway...prob is gate-level won't pass. > I want to know how can I detect fatal bugs in my code, besides RTL simu and > warning in ISE 4.1? > > > > > > "Jay" <kayrock66@yahoo.com> wrote in message > news:d049f91b.0203201704.55c58ac8@posting.google.com... > > How possible is it? Well if you're a new HDL guy then it's very > > possible, and if you're not, then its still possible. You should be > > able to run the same test bench on RTL or gates and have them both > > pass. > > > > "Kelvin Hsu" <qijun@okigrp.com.sg> wrote in message > news:<3c97f13b@news.starhub.net.sg>... > > > Hi, > > > > > > I am using Spartan-II chip, I want to know how much possibility that > > > the RTL and gate-level simulation don't match? > > > When they don't match, how can I detect that? It seemed that the > synthesis > > > report in ISE 4.1 doesn't give me a warning or error? > >Article: 41108
Rick - rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C98D60E.859D5A1A@yahoo.com>... > Bob Perlman wrote: > > > > Rick - > > > > A few comments/observations: > > > > 1) If your board stackup is at all conventional, trace impedances will > > fall somewhere in the range of 45 to 65 ohms. You can, with effort, > > get other impedances, but getting to 200 ohms will require tricks that > > you won't want to play. > > I am not at all clear on how you can guestimate the trace impedance to > be in such a narrow range. I was under the impression that it varied > directly with trace width. I could be using trace widths anywhere from > 4 mil to 10 mil. Further, the board stackup depends entirely on layer > count vs. power plane count. What were you assuming for these? I'm assuming that you're using a multi-layer board in which the height of the trace off the nearest plane is roughly the same as the trace width. For a 5-mil trace, for example, you'd be 5 mils from the nearest plane. You can violate this rule and make the height greater, thus increasing the impedance, but then crosstalk will bite you unless your trace-to-trace spacings are wide. And increasing the height of the trace above the plane does not increase the impedance rapidly. Here's a question that I ask students when I hold signal integrity courses: Suppose I'm in the space shuttle and I have a length of #30 AWG wire, and there's an infinitely wide ground plane sitting on the earth's surface 160 miles below. What's the impedance? Zillions of ohms? Any guesses? I'm also assuming that traces are narrow enough to fit between the vias for fine-pitch parts; this means they're not going to be extremely wide. These factors tend to put a bound on the practical range of achievable trace impedances. > > I am hoping that I can get away with 4 routing planes and two power > planes. But that is not clear at this point. I also would like to use > 5/5 width/space on the traces, and I think this is less likely to vary. > But I can certainly make the clock traces wider to lower the impedance. > > HJ has a T circuit analysis (or two) on the web that uses series > terminations at each end (all three). The series resistors at the > receiver were to damp resonant oscillations that can build up between > the receivers. I may give this a try if I can model it. > > > > 2) I don't know the strength of the C6711 clock driver. If it's > > strong enough to drive a Thevenin-equivalent parallel termination, and > > if you can tolerate the inevitable clock skew that arises from > > daisy-chaining the clock net, then use a single net and parallel > > termination. But be sure to check the weak/slow corner clock buffer > > drive. In my experience, the clock outputs of processor chips tend to > > be underpowered. (And they can be glitchy, too; a > > ground-bounce-related glitch on the clock output of TI's TMS320C31 > > nearly torpedoed one project I worked on.) > > I think I can afford to be accomodating in the skew since my daisy > chained route would be about 3 inches or ~500 ps. However the longest > single trace in a star configuration is only 1.4 inches or ~240 ps. The > driver spec gives a max of 2 ns (no min) for the rise time, so even if > it is 1 ns, my round trip is half the rise time. This is not ideal, but > I think it will likley work without termination. What happens when TI spins the die and the nominal risetime goes from 1ns to 0.6ns? > > 3) If (2) doesn't pan out, spring for one of the small zero-delay > > buffers, and drive each clock load with its own PLL output. If the > > zero-delay buffer has built-in series termination, great; if not, > > series-terminate each output. It'll cost you (not much) space and > > (not much) money. I never try to economize on either when generating > > and distributing clocks. > > Yes, I have thought about that, but small is a relative term and I am > loath to add another part to the parts list. > > I would love to model this circuit, but I don't think I want to plunk > down a few $k for a tool that will only be used one or twice per > design. I may try to find a friend at a company with the tool and > "borrow" it or let him run my tests after I come up with all the > relevant data. You can do surprisingly useful simulations with nothing more than the student version of PSpice. It's nowhere near as convenient as Hyperlynx, but it's free (or at least it used to be). Bob Perlman Cambrian Design Works http://www.cambriandesign.com > > -- > > 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: 41109
Matz wrote: > > Hi, > > I am using a XPLA3 (CoolRunner) Device XCR3064XL. Now I need a crystal oscillator with low frequency (8...12 MHz). I want to do it with a simple crystal and an inverter within the XPLA3 device. > Unfortunately the oscillator is not running. The input stucks on high signal. Although I disabled the XPLA3 internal PullUp Resistors. > Who can help me, how to do it. > > Best Regards > Matz Use a TinyLOGIC HCU04, either singly, or as a pair to increase the slew rate into the PLD pins. Also Philips did a 74HC6323, that was OSC+DIviders in SO8 -jgArticle: 41110
if clock is too fast the design output nothing at all. I am sure the clock is no problem. -- Best Regards, ----------------------------------------------------------------- Xu Qijun Engineer OKI Techno Centre (S) Pte Ltd Tel: 770-7049 Fax: 779-1621 Email: qijun@okigrp.com.sg "Tim" <tim@rockylogic.com.nooospam.com> wrote in message news:1016675701.23934.0.nnrp-07.9e9832fa@news.demon.co.uk... > Tried slowing down the test-bench "clock"? > > Kelvin Hsu wrote > > sure it's possible since i need to match the result with a C program, while > > i tried best > > to match the C result, gate level simulation is not correct. One constraint > > is that after I > > finished RTL and everything, I still don't know what problem the design was > > intended to > > solve...faint! > > While RTL simulation and synthesis all pass, w/o major error or warning...i > > am experienced > > HDL designer anyway...prob is gate-level won't pass. > > I want to know how can I detect fatal bugs in my code, besides RTL simu and > > warning in ISE 4.1? > > > > > > > > > > > > "Jay" <kayrock66@yahoo.com> wrote in message > > news:d049f91b.0203201704.55c58ac8@posting.google.com... > > > How possible is it? Well if you're a new HDL guy then it's very > > > possible, and if you're not, then its still possible. You should be > > > able to run the same test bench on RTL or gates and have them both > > > pass. > > > > > > "Kelvin Hsu" <qijun@okigrp.com.sg> wrote in message > > news:<3c97f13b@news.starhub.net.sg>... > > > > Hi, > > > > > > > > I am using Spartan-II chip, I want to know how much possibility that > > > > the RTL and gate-level simulation don't match? > > > > When they don't match, how can I detect that? It seemed that the > > synthesis > > > > report in ISE 4.1 doesn't give me a warning or error? > > > > > >Article: 41111
I've seen this in designs that have come across my desk. After looking at the designs closely, Synplicity is doing the correct thing. The code needs to be fixed, as it really is inferring a tristate output. In VHDL, all you need to do is to set the output type to "std_ulogic_vector", which is unresolved (thus it really can't tristate). That prevents this from happening in VHDL. How you would do it in Verilog, I don't know. Synplicity does supply a patch for 7.0.3, which puts it back into the original behavior. At work, we did put this patch on for 1 user. BTW, on the Verilog and VHDL synthesis SIGS on eda.org this has stirred up a discussion as well. > Unfortunately, their conclusion is completely opposite to my > understanding. I'm still not convinced that such logic mapping > is correct. > > Since Synplify is #1 in the FPGA synthesis market, a huge number > of engineers in the world are using Synplify to design FPGAs. > > I would like to ask everyone about this new feature of > Synplify 7.x. If you feel this feature is incorrect and > dangerous (or support Synplicity's arguments), please > send me an e-mail. I will present all e-mails I receive > to Synplicity (both for and against). > > Feedback / support to : synp_petition@usa.net > > I will post the update when I have something to report. > > Thank you for your attention. > Hope I can hear from many of you. > You can forward this to any other newsgroups or your friends > to get more feedbacks. > > Sincerely yours, > Aki Niimura - being a Synplify user since 1999 > > P/S I have created a Web site to list feedbacks I receive. > http://www.petition-synplify.0catch.com -- NAME: David W. Bishop INTERNET: dbishop@vhdl.org ( \ ) US MAIL: Hilton NY A Long time ago, \__\/ PHYSICAL: 43:17:17N 77:47:37W 281' In a Galaxy far, far away... | | For Supernova info: http://www.RochesterAstronomy.org/snimages/ | | For VHDL/Synthesis info: http://www.vhdl.org/siwg _/___\_ All standard disclaimers apply. [_______]Article: 41112
Bob Perlman wrote: > > Rick - > > rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C98D60E.859D5A1A@yahoo.com>... > > Bob Perlman wrote: > > > > > > Rick - > > > > > > A few comments/observations: > > > > > > 1) If your board stackup is at all conventional, trace impedances will > > > fall somewhere in the range of 45 to 65 ohms. You can, with effort, > > > get other impedances, but getting to 200 ohms will require tricks that > > > you won't want to play. > > > > I am not at all clear on how you can guestimate the trace impedance to > > be in such a narrow range. I was under the impression that it varied > > directly with trace width. I could be using trace widths anywhere from > > 4 mil to 10 mil. Further, the board stackup depends entirely on layer > > count vs. power plane count. What were you assuming for these? > > I'm assuming that you're using a multi-layer board in which the height > of the trace off the nearest plane is roughly the same as the trace > width. For a 5-mil trace, for example, you'd be 5 mils from the > nearest plane. You can violate this rule and make the height greater, > thus increasing the impedance, but then crosstalk will bite you unless > your trace-to-trace spacings are wide. And increasing the height of > the trace above the plane does not increase the impedance rapidly. > Here's a question that I ask students when I hold signal integrity > courses: Suppose I'm in the space shuttle and I have a length of #30 > AWG wire, and there's an infinitely wide ground plane sitting on the > earth's surface 160 miles below. What's the impedance? Zillions of > ohms? Any guesses? I would not have a clue. But I want to know how you plan to measure it and verify your answer! > I'm also assuming that traces are narrow enough to fit between the > vias for fine-pitch parts; this means they're not going to be > extremely wide. These factors tend to put a bound on the practical > range of achievable trace impedances. I don't know if that is a valid assumption. We are not talking about a bus of many signals. This is the clock route and it can be made any impedance or width I want. There is also not much point in using extremely narrow traces since many of the finer pitch parts can not be rounted between the pins unless you go to unmanufacturable line/space widths. > > I think I can afford to be accomodating in the skew since my daisy > > chained route would be about 3 inches or ~500 ps. However the longest > > single trace in a star configuration is only 1.4 inches or ~240 ps. The > > driver spec gives a max of 2 ns (no min) for the rise time, so even if > > it is 1 ns, my round trip is half the rise time. This is not ideal, but > > I think it will likley work without termination. > > What happens when TI spins the die and the nominal risetime goes from > 1ns to 0.6ns? If they respin the die, the max clock rate will go up and I will be reexamining the board for many reasons. > You can do surprisingly useful simulations with nothing more than the > student version of PSpice. It's nowhere near as convenient as > Hyperlynx, but it's free (or at least it used to be). > > Bob Perlman > Cambrian Design Works > http://www.cambriandesign.com You can, but it takes a lot of time and effort to get the input data right. I was willing to do some testing with Hyperlynx, but I think pSpice will be a rather large effort to ramp up on. I think that a good book will help me more easily and quickly. -- 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: 41113
Falk Brunner wrote:
>
> "Kevin Brace" <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> schrieb
> im Newsbeitrag news:a79fvc$qo1$1@newsreader.mailgate.org...
>
> > Compared to using a regular CLB FF, using an IOB OE FF makes Tsu
> > worse because routing distance will get longer, and will get only worst
> > if the device's die gets larger.
> > Also, for a path starting from unregistered control signals of PCI bus
> > (FRAME#, IRDY#, DEVSEL#, TRDY#, and STOP#) to AD[31:0] or C/BE#[3:0]'s
> > OE FFs, I already got 4 levels of 4-input LUT, and so far, I haven't
> > been successful reducing the level of LUT.
>
> I got it. But still, try to locate the critical stuff close together so that
> the signal dont have to cross the whol chip.
>
Even if the relevant LUTs are group inside an CLB, the signal
will still have to travel quite a long distance.
Therefore, I find it better not to use IOB OE FFs, and keep an OE FF
near the control signals to reduce routing distance.
> > But the problem is XST overrides my design of using one OE FF for
> > AD[31:0], and one OE FF for C/BE[3:0], and duplicates them 32 times and
> > 4 times, respectively.
> > Attaching "keep" attribute didn't help either.
>
> Did you check the settings in the synthesis options?? In the preferences,
> switch to "Advanced" properties, then there is a switch which allows you to
> set global generation of IOB FlipFlops. Just set it to Auto or OFF. Then
> just add the right attribute to the FF you want inside the IOB.
>
> attribute iob: string;
> attribute iob of
> {component_name|entity_name|label_name}:
> {component|entity|label} is "(true|false|auto)";
>
> Regards
> Falk
I already use Advanced options.
I already tried attaching Pack regsiters into IOB synthesis option to
individual FFs that will ultimately become IOB FFs, but the problem of
XST's IOB synthesis option is when a FF that will ultimately become an
IOB FF is located one or two hierarchy deep from the top module, the IOB
synthesis option attached seems to get ignored.
I believe this is a bug of XST.
So, the only way I figured out duplicating FFs that will become IOB FFs
is to use the global Pack registers into IOB option, and set it to Yes.
I am aware of XST's synthesis options, and I do use some of them
in my PCI IP core like a "keep" attribute to prevent signals from
getting optimized, and a "blackbox" attribute when I use the infamous
PCILOGIC (The secret IRDY# and TRDY# pin thing people always talk about.
After I figured it out, it doesn't seem like a big deal.) in my PCI IP
core.
I don't like adding XST specific synthesis options to my code because I
want to keep it vendor independent, so I almost always use a synthesis
constraint file, but adding the synthesis options directly into my code
didn't make any difference either.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 41114kayrock66@yahoo.com (Jay) wrote in message news:<d049f91b.0203201627.44fb0ed@posting.google.com>... > Why are you driving your timer with a different clock then your > processor that is reading it? > the timer can be driven by an external clock or an internal clockArticle: 41115
For all the spartan II FPGA based PCI cards, can I expect the bandwidth to be a full blown 33Mx4 MB/s? Also some cards seem to have implemented the PCI logic onto the FPGA already. One manufacture claims to have used 15K gates on the FPGA, and have left 135K gates left on the FPGA for other things. Just curious, if I download the code onto the FPGA, will I overwrite the orignal PCI logic, and from a HDL coding perspective, how do I interface the backend processing logic with their PCI design. JimmyArticle: 41116
Also, how would I know if the design I have is too big so that there wouldn't be enough resources on board to accomodate the design? Jimmy Jimmy Zhang wrote in message ... >For all the spartan II FPGA based PCI cards, can I expect the bandwidth to >be a full >blown 33Mx4 MB/s? > >Also some cards seem to have implemented the PCI logic onto the FPGA >already. One >manufacture claims to have used 15K gates on the FPGA, and have left 135K >gates left >on the FPGA for other things. Just curious, if I download the code onto the >FPGA, will >I overwrite the orignal PCI logic, and from a HDL coding perspective, how do >I interface >the backend processing logic with their PCI design. > >Jimmy > >Article: 41117
What makes them different in ISE 4.1?
Case A:
assign beta_X_x = beta_tmp * x;
assign beta_X_y = beta_tmp * y;
assign meanpos_temp1 = {y, {5'h00}} + beta_X_x - beta_X_y;
Case B:
assign meanpos_temp1 = beta_tmp * x + (6'd32 - beta_tmp) * y;
What did happen was that the gate level simulation of the two are different.
Case A is same as RTL simulation, Case B differnet.
Any comments?
--
Email: qijun@okigrp.com.sg
Article: 41118A question from a newbie, Can I program the FPGA via PCI interface thru device calls? Jimmy Kevin Brace wrote in message ... >Who is "they" in this case? >You mean, Insight Electronics? >All the reference design's software is for Windows 9x/NT/2000. >Another thing I should add is that according to another person who was >interested in this board said Insight Electronics discontinued the >board. >Supposedly, they are going to release a new one at some point. > > > >Kevin Brace (In general, don't respond to me directly, and respond >within the newsgroup.) > > > >Jimmy Zhang wrote: >> >> Just curious if they have a Linux version of the driver or not? >> >> JimmyArticle: 41119
Hi all, I have a small doubt.Say I have 2 cores whose GDSII files are available(layout files) and at later point of time I decided to integrate the two cores.Is it possible to integrate the two GDSII files at the fab itself?or should I repeat the whole process integrating the cores at RTL level? Please clear my doubt.I will be waiting for ur reply. Thanks and Regards - satyaArticle: 41120
Hi all,
I would like to initialize my ramb4_S4 with the following expression:
attribute INIT_00: string;
attribute INIT_00 of INST_RAMB4_S4: label
is"1F1E1D1C1B1A191817161514131211100F0E0D0C0B0A0980706050403020100";
Syntesizing is passed without error/warning, but translating tells:
WARNING:NgdBuild:526 - On the RAMB4_S4 symbol
"inst_ramb4_s4/Mram_mem_inst_ramb_0", the following properties are
undefined:
INIT_00, INIT_01, INIT_02, INIT_03, INIT_04, INIT_05, INIT_06,
INIT_07,
INIT_08, INIT_09, INIT_0A, INIT_0B, INIT_0C, INIT_0D, INIT_0E,
INIT_0F. A
default value of all zeroes will be used.
WARNING:NgdBuild:486 - Attribute "INIT_00" is not allowed on symbol
"inst_ramb4_s4" of type "ram_1024_4". This attribute will be
ignored.
Is it right, that XST (the Syntsize-tool in Xilinx free ISE WebPack) ignores
others than predefined attributes? Or what's wrong?
Thank's a lot!
Article: 41121you will need some software from Cadence, the Design Framework II, in which Virtuosso can be used to draw layouts. It is a very expensive software. -- Best Regards, ----------------------------------------------------------------- Xu Qijun Engineer OKI Techno Centre (S) Pte Ltd Tel: 770-7049 Fax: 779-1621 Email: qijun@okigrp.com.sg "satya" <satya@iwavesystems.net> wrote in message news:82741d43.0203210159.77f8de34@posting.google.com... > Hi all, > I have a small doubt.Say I have 2 cores whose GDSII files are > available(layout files) and at later point of time I decided to > integrate the two cores.Is it possible to integrate the two GDSII > files at the fab itself?or should I repeat the whole process > integrating the cores at RTL level? > Please clear my doubt.I will be waiting for ur reply. > > Thanks and Regards > - satyaArticle: 41122
Hello all, I have already searched in google for past posts regarding post-PAR and post-map simulation in modelsim but I still have a question. Post-map simulation includes the block delays (worst case) for the design but not the routing delays, so if the post-map simulation is OK and the timing analyzer after PAR reports no timing errors is it necessary to simulate the post-PAR simulation model? Greetings, HarrisArticle: 41123
better to perform post-PAR simu in case the synthesizer make mistakes. -- Best Regards, ----------------------------------------------------------------- Xu Qijun Engineer OKI Techno Centre (S) Pte Ltd Tel: 770-7049 Fax: 779-1621 Email: qijun@okigrp.com.sg "H.L" <alphaboran@yahoo.com> wrote in message news:a7cbc9$1d4f$1@ulysses.noc.ntua.gr... > Hello all, > I have already searched in google for past posts regarding post-PAR and > post-map simulation in modelsim but I still have a question. Post-map > simulation includes the block delays (worst case) for the design but not the > routing delays, so if the post-map simulation is OK and the timing analyzer > after PAR reports no timing errors is it necessary to simulate the post-PAR > simulation model? > > Greetings, > Harris > >Article: 41124
"Jimmy Zhang" <zhengyu@attbi.com> writes: > For all the spartan II FPGA based PCI cards, can I expect the > bandwidth to be a full blown 33Mx4 MB/s? > Unlikely, for any PCI implementation I would think. You can get that in a burst, but I doubt you will achieve sustained transfers of that magnitude. Anyone got any experience of real-world sustained transfer rates on PCI? > Also some cards seem to have implemented the PCI logic onto the FPGA > already. One manufacture claims to have used 15K gates on the FPGA, > and have left 135K gates left on the FPGA for other things. Just > curious, if I download the code onto the FPGA, will I overwrite the > orignal PCI logic, and from a HDL coding perspective, how do I > interface the backend processing logic with their PCI design. > You will need to implement their PCI logic with your logic. It will be supplied in HDL, or netlist form. The supplier *should* give you all the details, and hopefully some sample designs to work from. It's unlikely you will be able to reconfigure part of the FPGA with your own logic and leave the PCI bit alone. Apparantly the silicon is up to it in some families, but the tools don't make implementations like this straightforward. HTH, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conekt
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