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
Yes they can. Just make sure to install them to different directories. -ArthurArticle: 37351
--------------D1A431E6E27B31CF24212417
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
You need to post the full part numbers, eg. XC4010E-3HQ240C. The exact family,
speed grade and package are included in the part number and are important to
anyone who might be interested in the parts.
If these truely are the 4000 series without any suffix, the market is going to
be limited to a few buyers that have run out of parts for old designs. It is
not worth trying to use these old parts (which are about 10 years old) in new
designs, and the current software doesn't support them. Different story, if
they are 4000E or later families.
Eser Chamoglu wrote:
> From the e-bay page: "The lot includes 4003 (3), 4004 (4), 4010 (20) and
> 4013 (51)units."
>
> Is that 20 XC4010 FPGAs?
>
> "Jose I Quinones" <joseiq@mcumaster.com> wrote in message
> news:3C0E1EB3.A67493BF@mcumaster.com...
> > Hi all,
> >
> > I have two huge Xilinx FPGA lots advertised on ebay. Some of the chips
> > are used, but others I believe are new. Check the link below. Enjoy!
> >
> > JIQ
> >
> >
> http://cgi6.ebay.com/aw-cgi/eBayISAPI.dll?ViewListedItems&userid=avayan&incl
> ude=0&since=-1&sort=2&rows=25
--
--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
--------------D1A431E6E27B31CF24212417
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
You need to post the full part numbers, eg. XC4010E-3HQ240C. The
exact family, speed grade and package are included in the part number and
are important to anyone who might be interested in the parts.
<p>If these truely are the 4000 series without any suffix, the market is
going to be limited to a few buyers that have run out of parts for old
designs. It is not worth trying to use these old parts (which are
about 10 years old) in new designs, and the current software doesn't support
them. Different story, if they are 4000E or later families.
<p>Eser Chamoglu wrote:
<blockquote TYPE=CITE>From the e-bay page: "The lot includes 4003 (3),
4004 (4), 4010 (20) and
<br>4013 (51)units."
<p>Is that 20 XC4010 FPGAs?
<p>"Jose I Quinones" <joseiq@mcumaster.com> wrote in message
<br><a href="news:3C0E1EB3.A67493BF@mcumaster.com">news:3C0E1EB3.A67493BF@mcumaster.com</a>...
<br>> Hi all,
<br>>
<br>> I have two huge Xilinx FPGA lots advertised on ebay. Some of the
chips
<br>> are used, but others I believe are new. Check the link below. Enjoy!
<br>>
<br>> JIQ
<br>>
<br>>
<br><a href="http://cgi6.ebay.com/aw-cgi/eBayISAPI.dll?ViewListedItems&userid=avayan&incl">http://cgi6.ebay.com/aw-cgi/eBayISAPI.dll?ViewListedItems&userid=avayan&incl</a>
<br>ude=0&since=-1&sort=2&rows=25</blockquote>
--
<br>--Ray Andraka, P.E.
<br>President, the Andraka Consulting Group, Inc.
<br>401/884-7930 Fax 401/884-7950
<br>email ray@andraka.com
<br><A HREF="http://www.andraka.com">http://www.andraka.com</A>
<p> "They that give up essential liberty to obtain a little
<br> temporary safety deserve neither liberty nor safety."
<br>
-Benjamin Franklin, 1759
<br> </html>
--------------D1A431E6E27B31CF24212417--
Article: 37352
The VIrtex parts can support a fuly compliant PCI33 design, but the timing is not met over worst case unless you use that special TRDY
logic. I think 5v Virtex-6 just met the PCI66 timing.
Kevin Brace wrote:
> sdfjsd <kljfsdlkfskljfds@kjflsdkjlfsdklfdslfsdklsdf.com> wrote in message news:<3C0C6D5E.AC5972FC@kjflsdkjlfsdklfdslfsdklsdf.com>...
> > > http://208.129.228.206/solutions/kits/xilinx/spartan-iipci.html
> > >
> > > I used this kit to develop my own PCI IP core, and although the PCI IP
> > > core doesn't meet 33MHz PCI's timings (Tsu < 7ns and Tval < 11ns), the
> > > card somehow (barely) worked in two computers I tested it.
> > > It would have been nice if the Insight Electronics Spartan-II
> > > Development Kit used a 200K system gate part (XC2S200) instead of a
> > > 150K system gate part (XC2S150) even if the kit cost another $50 more,
> > > but overall I am very happy with the Insight Electronics Spartan-II
> > > Development Kit.
> >
> > What does "barely" worked really mean? I'm not intimately familiar
> > with PCI-protcol...I know that the PCI bus outputs (on a device)
> > are unregistered, to respond to the bus-protocol. Are you saying that
> > the XCS2-150-5 device was barely fast enough to meet 33MHz timing?
>
> What I meant from "'barely' worked" is that the PCI IP core I
> developed had Tsu of around 11ns if I remember it correctly, but it
> somehow worked in two computers I tested it.
> Some people said in this newsgroup that Xilinx devices run around 40%
> faster in room temperature (20 degrees celsius), so perhaps that is
> the reason it worked.
> I think the trick of a PCI IP core to meet 33MHz timings in my opinion
> will be to keep the levels of logic as low as possible, and take
> advantage of IOB FFs.
> Of course, if that doesn't work well, the LUTs will have to be
> floorplanned, but if there is about six levels of logic (one for input
> pin, one for IOB FF, and four levels of LUTs), even floorplanning
> won't help (that's the case in my case).
> In this case, I am using Spartan-II speed grade -5, but speed grade -6
> should meet timings if I floorplanned it.
>
> >
> > Xilinx brazenly boasts that their Virtex family (the old 0.25micron
> > family) supports PCI66MHz/64-bit. Your experience suggests that
> > while this can certainly be true, it's not an easily achievable
> > target for someone not designing specifically for FPGA.
>
> I guess it depends on the skill of the designer, but I think
> even 33MHz PCI's Tsu (Tsu < 7ns) is hard to meet for my design . . .
>
> >
> > Someone I know wants to develop a PCI-core for an in-house project.
> > He threw around the idea of prototyping it on an FPGA-board.
> > I advised him against it, simply because a lot of his design
> > implementation would be governed by the FPGA's architectire
> > (vs the actual production goal of a standard cell ASIC process.)
> >
> > I reasoned he'd be wasting a lot of dev time making the core
> > work on an FPGA-device, i.e. wasting dev-time "designing for
> > FPGA", instead of just designing for the final project goal.
> >
> > sorry if this is a redundant question...
>
> Although I will not make any guarantees, even if the FPGA
> prototype doesn't meet 33MHz PCI Tsu, if it somehow works in actual
> system, I think that lowers the risk of an ASIC not working properly
> from the first time.
> Since the ASIC respin costs time and money, making sure it sort of
> works in an FPGA before ASIC tapeout might save time and money in the
> long run.
>
> Kevin Brace (don't respond to me directly, respond within the
> newsgroup)
--
--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: 37353Can someone direct me to a source that have description of the different library parts in Orcad (ver. 7.2) schematic capture for Xilinx's 4000 series (e.g. XC4010XL)? I'm particularly looking for the difference pin description on some of these parts. I'm using Xilinx Alliance 1.5.Article: 37354
Hi All, I have developed a ISP state machine which takes the SVF file generated by Xilinx Webpack software V4. After a week of trying to find the problem with my software I observe that, A comparison of the programming signals generated by my software and the Xilinx download software show a slight discrepancy. For example, an XVC300 requires about 1.8million TCLK's to download the actual logic, My state-machine does this according to the number specified by the svf file. The Xilinx download applies an extra data bit !! I can manually modify the svf file to add one to this 1.8Mbits and everything works OK. ( There just happens to be an extra bit defined) Has anyone else had this problem? I will be onto Xilinx after the weekend but It maybe something so simple in my state-machine but everything else checks out. Help DaveArticle: 37355
I'm using FPGA Editor to (at least try to) manually route. I'm running into a big obstacle with high-fanout nets. Take CLK. I can route no problem from the GCLK buffer to the first CLB pin, and have the route be the one I'd like. But then if I try to add a second pin to the net, one of 2 things happens: 1) In spite of me specifying a manual route the autorouter seems to take over and adds a second complete route from the clock buffer to the second pin, complete with use of a second global routing longline, or 2) I must route the 3 pins at the same time, and then the software forces an entirely different route for the whole net, which is not the one I wanted. What I really want to do is define the longline routing in the first route connection from the buffer to the first clock pin. Then in subsequent routes, I want to hang the other clock pins off that same longline. For some reason, the Xilinx S/W doesn't want to let me do this. What do I do to get this result? Thanks. Alex Rast arast@qwest.net arast@inficom.comArticle: 37356
Apple II's 6502 runs at 1.022 MHz = 14.31818/14. 14.31818 MHz is 4X the NTSC color burst frequency, which is how Woz did a color graphic display with nothing more than DRAMs and a little 74LS TTL. If you take the motherboard design out of the old Apple II manual, insert a 6502 design where the 6502 goes, and run it at 14.31818 MHz, you'll be working fine. I know all this because 1) I wirewrapped an Apple II off the schematics back in about 1980, and 2) I used the Apple II motherboard design as the first design I emulated in the first logic emulator prototype (Realizer) I built back in 1988-9. That used XC3020s interconnected by XC2064s. I wired in a real 6502, Apple floppy controller, kbd, joystick, etc. The host would download the FPGAs, pulse reset, and "beep rattle rattle rattle", it booted off the floppy and ran Choplifter. To prove it was an emulation I developed a second version with a few gates flipped in the graphics logic. So after running the true Apple II I'd download one with the display upside down. Playing Choplifter (a 2-D helicopter game) that way was a hoot. Made a great logic emulation demo. Even the marketing guys understood it ;-) Woz (Steve Wozniak) is a genius. His Apple II is the best digital design I have ever seen in my life. --Mike Butts PS: To emulate the floppy controller you'll have to get the contents of the little PROM Woz used in its state machine.Article: 37357
Hi, I've had this "problem" before. It drove me nuts until I found out what was going on. I believe, if you select File-->Main Properties, you will get a dialog box that allows you to change the behavior of the tool. In the Route Options pane, you must at least turn off the Automatic Routing option. I typically turn off the other two, too (Enhanced Manual Routing and Delay Based Routing) because when I'm routing by hand, I am trying to achieve a specific result. I also find it useful, when routing by hand, to turn off the Stub Trimming in the Programs Option pane of this dialog box. Stub Trimming "hides" the "antennas" on the used routing resources, but when you are zoomed in up close and personal, it helps to know what resources are in use; you can't use a resource twice, even if the graphical representation of the two routed nets does not intersect (this is particularly useful with hexes and long lines). Hope that helps, Eric Crabill Alex Rast wrote: > > I'm using FPGA Editor to (at least try to) manually route. I'm running into a > big obstacle with high-fanout nets. Take CLK. I can route no problem from the > GCLK buffer to the first CLB pin, and have the route be the one I'd like. But > then if I try to add a second pin to the net, one of 2 things happens: > > 1) In spite of me specifying a manual route the autorouter seems to take over > and adds a second complete route from the clock buffer to the second pin, > complete with use of a second global routing longline, or > > 2) I must route the 3 pins at the same time, and then the software forces an > entirely different route for the whole net, which is not the one I wanted. > > What I really want to do is define the longline routing in the first route > connection from the buffer to the first clock pin. Then in subsequent routes, > I want to hang the other clock pins off that same longline. For some reason, > the Xilinx S/W doesn't want to let me do this. What do I do to get this > result? > > Thanks. > > Alex Rast > arast@qwest.net > arast@inficom.comArticle: 37358
In article <3C1168C2.5637145@xilinx.com>, Eric Crabill <eric.crabill@xilinx.com> wrote: > >Hi, > >I've had this "problem" before. It drove me nuts until I >found out what was going on. > >I believe, if you select File-->Main Properties, you will >get a dialog box that allows you to change the behavior of >the tool. > >In the Route Options pane, you must at least turn off the >Automatic Routing option. I typically turn off the other >two, too (Enhanced Manual Routing and Delay Based Routing) >because when I'm routing by hand, I am trying to achieve a >specific result. Yes, I turned them all off. No go. I would always turn such options off as a matter of course. The first thing I do when getting any new piece of S/W is to go through every option setting in every dialog that I can find and turn off all "auto-" anything. The Manual Route menu item remains greyed. (Whine begins here) Why must so much software (or so many programmers) imagine it's more intelligent than you are, and try to prevent you from making what *it* thinks are mistakes? If I want to do something stupid, why not let me? And if the answer, from software companies, is that otherwise people would imply that the company were to blame for a stupid mistake on the part of the user, are people really so afraid for their jobs? (both at the S/W company and the user) If so, why not quit now and save yourself the torture of worrying about whether you'll be fired tomorrow? (end of whine) Anyway, with that data in mind, what am I overlooking? Is there anything else I must do to turn off all "intelligence" on the part of the software? > >Alex Rast wrote: >> >> I'm using FPGA Editor to (at least try to) manually route. I'm running into a >> big obstacle with high-fanout nets.... >> >> What I really want to do is define the longline routing in the first route >> connection from the buffer to the first clock pin. Then in subsequent routes, >> I want to hang the other clock pins off that same longline. For some reason, >> the Xilinx S/W doesn't want to let me do this. What do I do to get this >> result? Alex Rast arast@qwest.net arast@inficom.comArticle: 37359
Hi all, We are using the Block RAM's inside the Spartan-II device in order to get a synchronous true dual-ported RAM buffer. The block RAM buffer clocks are being sourced from two different clock domains. When using the design in real word we get sometimes 'data-flicker' on the data we push from one clock domain to the other, not always, only sometimes. As a second test we put in values on one side PortA using a staircase generator - well a counter -. On PortB of the block RAM we read out the the 'staircase'. However sometimes we see something like an interference, a modulation on top of our digital generated staircase, maybe once per thousand scans. The dual ported synchronous RAM we generated with the CoreLoigc tool from Xilinx using version 3.1i. Those are really true dual-ported, right ?? The clocks are really asynchronous to eatch other ... The question: How to you have to apply timing constraints for the block ram, or is it not needed? Actually we did constraint the two clocks. Is that enough, or is there a need for an additional block ram constraint ?? clk ist the clock for PortA dsp_clock is the clock for PortB Reading and writing does interleave, but not an the same address ... NET "clk" TNM_NET = "clk"; TIMESPEC "TS_CLK" = PERIOD "clk" 40 MHz HIGH 50 %; NET "chk_clk" TNM_NET = "chk_clk"; TIMESPEC "TS_CHK_CLK" = PERIOD "chk_clk" 55 MHz HIGH 50 %; Any idea how to furhter find the reason for the problem? thanks in advance markus -- ******************************************************************** ** Meng Engineering Telefon 056 222 44 10 ** ** Markus Meng Natel 079 230 93 86 ** ** Bruggerstr. 21 Telefax 056 222 44 10 ** ** CH-5400 Baden Email meng.engineering@bluewin.ch ** ******************************************************************** ** Theory may inform, but Practice convinces. -- George Bain **Article: 37360
"Markus Meng" <meng.engineering@bluewin.ch> schrieb im Newsbeitrag news:3c121b73_3@news.bluewin.ch... > Hi all, > > We are using the Block RAM's inside the Spartan-II device > in order to get a synchronous true dual-ported RAM buffer. > > The block RAM buffer clocks are being sourced from two different > clock domains. > > When using the design in real word we get sometimes 'data-flicker' on the > data we push from one clock domain to the other, not always, > only sometimes. As a second test we put in values on one side PortA > using a staircase generator - well a counter -. On PortB of the block RAM > we read out the the 'staircase'. However sometimes we see something like > an interference, a modulation on top of our digital generated staircase, > maybe > once per thousand scans. The dual ported synchronous RAM we generated > with the CoreLoigc tool from Xilinx using version 3.1i. Those are really > true > dual-ported, right ?? The clocks are really asynchronous to eatch other ... They are. > The question: How to you have to apply timing constraints for the block > ram, or is it not needed? Actually we did constraint the two clocks. Is that > enough, or is there a need for an additional block ram constraint ?? ;-)) The constraints only make sure that data within ONE clock domain makes it way from FlipFlop to FlipFlop or RAM within on clock cycle. It does NOT do anything about synchronization. This is YOUR part. It is the classic data crossing clock domain problem, and so it can (and must) be solved. You need to synchronize both port access somehow, you have to make sure that the FF on the synchonizer going metastable dont kick your system. Go to the Xilinx website and have a look at the TechXclusives, there is one article discussing exactly your problem. There are also some appnotes about asynchronous FIFOs, read them carefully. Twice. Or as long as you really got the point of asynchronous clocks. > Any idea how to furhter find the reason for the problem? See avove. -- MfG FalkArticle: 37361
You cannot read and write the same location simultaneously with the Virtex block
RAM. Well, you can but the read data may be corrupted. Are you doing anything
to make sure the read and write ports don't have an overlapped access?
Markus Meng wrote:
> Hi all,
>
> We are using the Block RAM's inside the Spartan-II device
> in order to get a synchronous true dual-ported RAM buffer.
>
> The block RAM buffer clocks are being sourced from two different
> clock domains.
>
> When using the design in real word we get sometimes 'data-flicker' on the
> data we push from one clock domain to the other, not always,
> only sometimes. As a second test we put in values on one side PortA
> using a staircase generator - well a counter -. On PortB of the block RAM
> we read out the the 'staircase'. However sometimes we see something like
> an interference, a modulation on top of our digital generated staircase,
> maybe
> once per thousand scans. The dual ported synchronous RAM we generated
> with the CoreLoigc tool from Xilinx using version 3.1i. Those are really
> true
> dual-ported, right ?? The clocks are really asynchronous to eatch other ...
>
> The question: How to you have to apply timing constraints for the block
> ram, or is it not needed? Actually we did constraint the two clocks. Is that
> enough, or is there a need for an additional block ram constraint ??
>
> clk ist the clock for PortA
> dsp_clock is the clock for PortB
>
> Reading and writing does interleave, but not an the same address ...
>
> NET "clk" TNM_NET = "clk";
> TIMESPEC "TS_CLK" = PERIOD "clk" 40 MHz HIGH 50 %;
>
> NET "chk_clk" TNM_NET = "chk_clk";
> TIMESPEC "TS_CHK_CLK" = PERIOD "chk_clk" 55 MHz HIGH 50 %;
>
> Any idea how to furhter find the reason for the problem?
>
> thanks in advance
>
> markus
>
> --
> ********************************************************************
> ** Meng Engineering Telefon 056 222 44 10 **
> ** Markus Meng Natel 079 230 93 86 **
> ** Bruggerstr. 21 Telefax 056 222 44 10 **
> ** CH-5400 Baden Email meng.engineering@bluewin.ch **
> ********************************************************************
> ** Theory may inform, but Practice convinces. -- George Bain **
--
--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: 37362Hello all, Another novice question here that I would appreciate some help with. I'm writing the code for a simple ISA interface, simple being that this card is only going to interrupt the processor (at 1kHz) and place 16 bit data blocks on the bus when the address is decoded. My question is about syncronization. Do I need to syncronize to the bclk pin on the ISA bus or should I bring that clock into my 100MHz clock domain to syncronize to that? Or is syncronization even necessary on the ISA bus. In all of the limited documentation that I have found on the ISA bus it isn't very specific. I would appreciate if anyone has more specific technical documentation on the bus if they could email me a copy or a snippit of some code verified would be great. No one seems to care about the ISA bus anymore, it's all PCI but we are using PC/104 gear in our designs and therefore are at present using the ISA bus. A follow up question is; is it better to design using a finite state machine approach for the ISA bus, or because mine is a scaled down version, is it necessary? I have done a quick VHDL design but it at present does not include any syncronization. Thanks for the help JasonArticle: 37363
Is there any way to get Aldec FSM editor to produce a sequential state machine (vs combinatorial) ? thanksArticle: 37364
The Virtex/Spartan-II BlockRAMs are really, truely dual-ported in every sense of the word. Each port operates synchronously ( i.e. even a read is a clocked operation!) and each port has its own address, data-in, data-out, clock, CE, WE lines. The two ports share only the common data "pool". The only case where you have to be careful is when you access the same location from both ports and one or both accesses is a write operation. Since both read and write are asynchronous operations, i.e. they are executed by a "glitch-maker" triggered by the active clock edge, you can only get in problems when these glitches overlap. Their width is of the order of 1 ns ( I am at home right now...) No normal timing constraint will solve your problem. You have to do some thinking and reading. Again: The problem occurs only with uncorrelated "simultaneous" accesses from both ports to the same location, and only if one or both is a write access. Hope this helps. Peter Alfke, Xilinx Applications ======================================== Markus Meng wrote: > Hi all, > > We are using the Block RAM's inside the Spartan-II device > in order to get a synchronous true dual-ported RAM buffer. > > The block RAM buffer clocks are being sourced from two different > clock domains. > > When using the design in real word we get sometimes 'data-flicker' on the > data we push from one clock domain to the other, not always, > only sometimes. As a second test we put in values on one side PortA > using a staircase generator - well a counter -. On PortB of the block RAM > we read out the the 'staircase'. However sometimes we see something like > an interference, a modulation on top of our digital generated staircase, > maybe > once per thousand scans. The dual ported synchronous RAM we generated > with the CoreLoigc tool from Xilinx using version 3.1i. Those are really > true > dual-ported, right ?? The clocks are really asynchronous to eatch other ... > > The question: How to you have to apply timing constraints for the block > ram, or is it not needed? Actually we did constraint the two clocks. Is that > enough, or is there a need for an additional block ram constraint ?? > > clk ist the clock for PortA > dsp_clock is the clock for PortB > > Reading and writing does interleave, but not an the same address ... > > NET "clk" TNM_NET = "clk"; > TIMESPEC "TS_CLK" = PERIOD "clk" 40 MHz HIGH 50 %; > > NET "chk_clk" TNM_NET = "chk_clk"; > TIMESPEC "TS_CHK_CLK" = PERIOD "chk_clk" 55 MHz HIGH 50 %; > > Any idea how to furhter find the reason for the problem? > > thanks in advance > > markus > > -- > ******************************************************************** > ** Meng Engineering Telefon 056 222 44 10 ** > ** Markus Meng Natel 079 230 93 86 ** > ** Bruggerstr. 21 Telefax 056 222 44 10 ** > ** CH-5400 Baden Email meng.engineering@bluewin.ch ** > ******************************************************************** > ** Theory may inform, but Practice convinces. -- George Bain **Article: 37365
Ray Andraka wrote: > The VIrtex parts can support a fuly compliant PCI33 design, but the timing is not met over worst case unless you use that special TRDY > logic. I think 5v Virtex-6 just met the PCI66 timing. > Ray, I couldn't use the TRDY stuff way back when in the very early Virtex days when I designed our PCI i/f since FPGAEditor (or was it still EPIC ?) was so flakey it wouldn't stand up long enough for me to even see how it worked, let alone try to use it. So I had to struggle quite hard to get to within 1.0-1.5nsec in a Virtex-4 with the autoplace tools [No FloorPlanner back then for Virtex parts] i.e. a Tsu of ~8.5nsec. As a result with the much improved 3.3i tools & a VirtexE-6 I'm now 1.0-1.5nsec on the right side of the spec. Getting to the PCI66 3nsec. spec still looks challenging in a VE-6 part & I may yet end up having to use the "magic TRDY" paths.Article: 37366
Rick Filipkiewicz wrote: > ... > As a result with the much improved 3.3i tools & a VirtexE-6 I'm now > 1.0-1.5nsec on the right side of the spec. > > Getting to the PCI66 3nsec. spec still looks challenging in a VE-6 > part & I may yet end up having to use the "magic TRDY" paths. And by the way, the 3.3i tools handle the PCILOGIC aka "magic TRDY" just fine for me, despite Xilinx claims that they do not support it. That includes ngdbuild, map and par, and includes support for timing constraints on paths that pass through the PCILOGIC. I did not find that the use of fpga_editor was required.Article: 37367
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<9ut9lj$aq0uv$1@ID-84877.news.dfncis.de>... > "Markus Meng" <meng.engineering@bluewin.ch> schrieb im Newsbeitrag > news:3c121b73_3@news.bluewin.ch... > > > Hi all, > > > > We are using the Block RAM's inside the Spartan-II device > > in order to get a synchronous true dual-ported RAM buffer. > > > > The block RAM buffer clocks are being sourced from two different > > clock domains. > > > > When using the design in real word we get sometimes 'data-flicker' on the > > data we push from one clock domain to the other, not always, > > only sometimes. As a second test we put in values on one side PortA > > using a staircase generator - well a counter -. On PortB of the block RAM > > we read out the the 'staircase'. However sometimes we see something like > > an interference, a modulation on top of our digital generated staircase, > > maybe > > once per thousand scans. The dual ported synchronous RAM we generated > > with the CoreLoigc tool from Xilinx using version 3.1i. Those are really > > true > > dual-ported, right ?? The clocks are really asynchronous to eatch other > ... > > They are. > > > The question: How to you have to apply timing constraints for the block > > ram, or is it not needed? Actually we did constraint the two clocks. Is > that > > enough, or is there a need for an additional block ram constraint ?? > > ;-)) The constraints only make sure that data within ONE clock domain makes > it way from FlipFlop to FlipFlop or RAM within on clock cycle. It does NOT > do anything about synchronization. This is YOUR part. It is the classic data > crossing clock domain problem, and so it can (and must) be solved. You need > to synchronize both port access somehow, you have to make sure that the FF > on the synchonizer going metastable dont kick your system. Go to the Xilinx > website and have a look at the TechXclusives, there is one article > discussing exactly your problem. There are also some appnotes about > asynchronous FIFOs, read them carefully. Twice. Or as long as you really got > the point of asynchronous clocks. > > > Any idea how to furhter find the reason for the problem? > > See avove. Hi Falk, maybe my english is not clear enough. The address generator and the data FF for PortA are clocked with the clk for PortA. The same applies for the address generator and the data FF on PortB of the DualPorted RAM block. Those parts are clocked with the clock for PortB of the dual ported memory. The access can interleave, however the DPM is somehow 'splitted' in two pages. When a read burst appears on page 0, a write burst can only appear on page 1. Therefore what kind of additional syn- chronization is needed in your opinion. I don't get this point best regards markusArticle: 37368
If you use a multiplier does that mean you can't use the block ram that is associated with it and vice versa. For example, the virtex II 250 has 24 multipliers and 24 block ram. If I use all of the multipliers does that mean I cannot use any of the block ram. thanks SWArticle: 37369
"Markus Meng" <meng.engineering@bluewin.ch> schrieb im Newsbeitrag news:aaaee51b.0112081131.401dd1f4@posting.google.com... > > > The block RAM buffer clocks are being sourced from two different > > > clock domains. ^^^^^^^^^^^^^^^^^^ > > > When using the design in real word we get sometimes 'data-flicker' on the > > > data we push from one clock domain to the other, not always, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Hi Falk, > > maybe my english is not clear enough. The address generator and According to your email address, I suppose you speak deutsch better ;-) ?? So we can turn to german. One of the specialist here speaks german too, Hello Peter. ;-) I dont know about the other guys. (Sauerkraut and Auf Wiedersehen doesnt count ;-) > the data FF for PortA are clocked with the clk for PortA. The > same applies for the address generator and the data FF on PortB > of the DualPorted RAM block. Those parts are clocked with the clock > for PortB of the dual ported memory. Yes, but you wrote you have TWO clock domains. Does this statement still apply? If you have just ONE clock domain, the failure is in your logic. IF you have TWO INDEPENDEND clock domains, you need some kind of synchronization to make sure you dont write to an address when the other port reads this address. > The access can interleave, however the DPM is somehow 'splitted' > in two pages. When a read burst appears on page 0, a write burst > can only appear on page 1. Therefore what kind of additional syn- > chronization is needed in your opinion. I don't get this point How does one port "know" what the other side is doing? One port must signal to the other "Hey, Iam going to do a burst on my page, keep your hand off it". If the other side recieves this message, it knows what to do (hopefully ;-) Do you have some kind of this logic in your design? -- MfG FalkArticle: 37370
Yes, in a -6 I believe you will need the TRDY box to make the timing for PCI66, and even then it *just* makes it. Unfortunately, that TRDY
box is onlly accessible in the FPGA editor and it is pretty much undocumented, at least publicly.
Rick Filipkiewicz wrote:
> Ray Andraka wrote:
>
> > The VIrtex parts can support a fuly compliant PCI33 design, but the timing is not met over worst case unless you use that special TRDY
> > logic. I think 5v Virtex-6 just met the PCI66 timing.
> >
>
> Ray,
>
> I couldn't use the TRDY stuff way back when in the very early Virtex days when I designed our PCI i/f since FPGAEditor (or was it still
> EPIC ?) was so flakey it wouldn't stand up long enough for me to even see how it worked, let alone try to use it. So I had to struggle
> quite hard to get to within 1.0-1.5nsec in a Virtex-4 with the autoplace tools [No FloorPlanner back then for Virtex parts] i.e. a Tsu of
> ~8.5nsec.
>
> As a result with the much improved 3.3i tools & a VirtexE-6 I'm now 1.0-1.5nsec on the right side of the spec.
>
> Getting to the PCI66 3nsec. spec still looks challenging in a VE-6 part & I may yet end up having to use the "magic TRDY" paths.
--
--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: 37371
YOu can use both, with the stipulation that some of the connections are shared.
If you use the block ram to provide coefficients to one input of the multiplier
you get the full benefit of both. If not, there are restrictions on the width
of the block ram port.
Sul Weh wrote:
> If you use a multiplier does that mean you can't use the block ram that is
> associated with it and vice versa.
> For example, the virtex II 250 has 24 multipliers and 24 block ram. If I
> use all of the multipliers does that mean I cannot use any of the block ram.
>
> thanks
>
> SW
--
--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: 37372Creating an Orcad symbol from any ASCII file is very simple. Check out: http://www.fpga-faq.com/FAQ_Pages/0027_Creating_PCB_symbols_for_FPGAs_using_ORCAD.htm Rotem Gazit Design Engineer MystiCom LTD 1 Hazoran St P.O. Box 8364 Netanya 42504, Israel Phone: ++972 9 8636424 Fax : ++972 9 8636466 mailto:rotemg@mysticom.com http://www.mysticom.com/Article: 37373
Ray Andraka wrote: > > Yes, in a -6 I believe you will need the TRDY box to make the timing > for PCI66, and even then it *just* makes it. Unfortunately, that TRDY > box is onlly accessible in the FPGA editor and it is pretty much > undocumented, at least publicly. > Create a small test design with the block in it. Run ngd2vhdl. The result is a small file with a VHDL model of the PCILOGIC. And as I mentioned "above", I am able to use the PCILOGIC block with the Xilinx 3.3i (and earlier) tools such as ngdbuild, map, and par. -- DuaneArticle: 37374
"Arie Zychlinski" <ariez@attglobal.net> wrote in message news:<3c00ae89_4@news3.prserv.net>... > I would be much obliged to learn for your experience with the ALTERA's > Mercury CDR using the M1GXCVR core. we intend to use it in a new project for > 800 Mbps links. > thank you in advance. Hi Arie, Mercury CDR is capable of speeds at up to 1.25 Gbps per channel and a total CDR bandwidth of 45 Gbps. http://www.altera.com/literature/an/an130.pdf >Asher<
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