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
Will Quartus automatically allocate RAM to both M9K and M144K blocks? Is there any performance improvement to having it all be in a single block type (M144K for example)? I need to allocate 6 Mbits of RAM in an application. (I'd prefer it to be self-contained on the FPGA.) I'm comparing Xilinx's Virtex-6 to Altera's Stratix IV. The Virtex-6 ranges in size from 5,616 kbits up to 38,304 kbits. The Stratix IV ranges in size from 8,244 kbits up to 20.736--however that includes both M9K and M144K. If I count only M144K, I get sizes between 2,304 and 9,216. I'd appreciate any advice that helps me make this decision between Virtex-6 and Stratix-IV.Article: 142126
Does anyone know of anyone that can shp a Virtex-6 PCIe development board (within about 4 weeks)? Xilinx still doesn't seem to have their evaluation/development kits for Virtex-6 ready to ship.Article: 142127
"Andy Peters" <google@latke.net> wrote in message news:89bb1088-36f1-435c-8107-284367a3ac23@13g2000prl.googlegroups.com... The project is in an svn repo. The great thing about this now-deleted feature was that it boiled the ISE project file down to a couple of tcl scripts which are scc-friendly. The only other things in the repo are the sources and a .ucf. ========= The <project>.xise file serves the need, without exporting or importing. Now if only I can get it to stop polluting the project root with all those generated files.Article: 142128
Good Morning. I want to get started on fpga development, but I cant decide on what board and gate count to get. I'm inclined tho the Xilinx spartan boards ( diligent BASYS or the Nexys2 ) boards. And linux compatibility for me is a must, since I use linux on my home pc. I'm planing to start on simple designs, so i prefer an inexpensive solution, but well documented. I have a background on electronics and i'm currently studying C.S. Best Regards Jaerder Sousa.Article: 142129
Peter Alfke wrote: > Interesting. > So let's dig deeper: > The problem is really not the clock glitch by itself. > It is any uncontrolled address change during the metastable-catching > timing window right before any rising clock edge (if the clock is > enabled). > > So either: > disable the clock, > or keep the address constant for a set-up time prior to any rising > clock edge > or do both. Do you have some tips how to do this? I guess using a PLL for the input clock is a good beginning. But I don't know in advance when the clock will change. How fast does the PLL output changes and lock again? There is another interesting case (maybe a bit theoretical): Slow changes of the external clock frequency, so that the PLL never gets unlocked, but the frequency rises above the allowed maximum clock. The PLL has some internal registers for controlling the VCO. Is it possible to read these registers? This would not provide an accurate frequency measurement, but maybe at least it would be possible to say that the frequency is too high. And a final question: In the PLL summary report is a PLL property "freq max lock". Is it possible to change this frequency? I don't see this property in the mega wizard. > In other words: Never use the internal BlockRAM address register as a > synchronizer that might (occasionally) go metastable, and screw up the > address decoder. I don't understand you. My problem is, that I clock the process, which reads the BRAM with the same clock as the BRAM clock itself, something like this: PROCESS(audioClock, reset) BEGIN if reset = '1' then ... elsif rising_edge(audioClock) then ... statusRamRdaddress <= statusRamRdaddress + 1; aesOutSubFrame <= statusRamQ & "00" & audioData; audioClock is a multiply of the AES3 bit clock. I don't read the BRAM each clock, but I use counters and sync detection for locking the output to the input. It is much easier to have only one clock for all the audio subsystem entities. So is this "using the internal BRAM address register as a synchronizer"? After writing this, maybe a clean solution for the problem would be to use another, independant clock for the logic of the audio system, with some more temporary BRAMs and then the AES3 serializer output entity, only, uses the external derived clock and reads from the temporary BRAM. But this would be a major redesign and would add some more latency for the audio path. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142130
On Jul 25, 11:06=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > On Jul 25, 12:05=A0pm, Brian Davis <brimda...@aol.com> wrote: > > > > > > > Antti wrote: > > > > i cant see the workaround be 100% in the case external clocks > > > and DCM's are involved > > > the code in FPGA can not foresee the ext clock to change > > > and the DCM would go mad, and the ROM is corrupted... > > > =A0That is precisely the problem. > > > > there are no crystal balls inside FPGA to forecast the coming > > > in the future loss of external clock signal (to de-assert CE in time) > > > My 2007 explanation to Peter was that the hardware designer > > required PHD (Psychic Hardware Design) skills. > > >http://groups.google.com/group/comp.arch.fpga/msg/a7723a92f8b90735 > > " > > " =A0But real world clocking systems that monitor DCM status, > > " or perform automatic clock failovers, CAN NOT USE ENABLE > > " (OR AN ENABLED CLOCK) TO PROTECT BLOCK ROM CONTENTS!!! > > " > > " =A0Unless, of course, you have mastered the obscure art of > > " Psychic Hardware Design, and can design clock enable logic > > " that knows ahead of time when the DCM will unlock, the DRO > > " suffer a phase hit, or the clock recovery PLL hiccup :) > > " > > > > i dont see ANY workaround for this, except that all DCM > > > must be clocked from oscillators that are running all the time > > > or then BRAMs can not be clocked from dcm/ext clock at all > > > =A0Yes, or perhaps else scrubbed/ECC'd with one port. > > > =A0I have explained this aspect of the BRAM problem to Peter > > repeatedly over the past few years, but he continues to claim > > their "fix" is all that is needed. > > > Brian > > C'mon, let's not get nasty. > This is a deep-rooted "feature" in all Xilinx (and Altera) BlockRAMs, > and I claim it has a solid work-around: > Enable the clock only when you are interested in the read data > output. > Obviously, you don't really care about the read data when the clock is > undefined and glitching. > So make clock disable the default, and only enable the clock when you > really care about the read data. > I wish all problems had that good a work-around. > Peter Alfke- Hide quoted text - > > - Show quoted text - Dear Peter, nobody is getting nasty (and yes i looked into a mirror recently) the "feature" is not a feature, imagine xilinx advertising it: Virtex-XXX * abcde * xxx DSP blocks at yyy MHz * asdfg * Block RAMs with built in corruption * zxcvb xilinx is not advertising Virtex family like that, those its not a feature but a real bug. a bug that may go for years undetected, and then hit very hard, also on existing designs. I just realized that i have 2 current active designs where the "feature" may hit one is based on Virtex-4 and uses MGT optical links for multi board clock syncronisation. It is not possible to guarantee when the boards upstream are powered off or on, those the clock to the downstream slaves may have some clock glitch during sync fall back, so at least theretically some BRAM clocked from the derived ext may get corrupted. maybe it will never happen, but I am failing to see 100% workarounds a clock sync loss can not be predicted, so it not possible to disable the affected BRAMs in good time (before the one bad clock edge reaches them) the other design involves AES3, if you look other replies then Frank is concerned about AES3 as well.. ok, in light of the Virtex BRAM/ROM issue i see no way to use the AES3 bitclock directly, that is the only possibility is to oversample the clock and use free running system clock to clock the BRAM's but this means there is jitter in the AES3 clock, what is also bad solution is to force FPGA reconfiguration each time sync on ext clock is lost, but well that also not a real solution. maybe the issue is over accelerated now, and that in the real life in most cases there would be no issue, but its very hard for the designer to know, if there would be a potential corruption or not AnttiArticle: 142131
Frank Buss wrote: > And a final question: In the PLL summary report is a PLL property "freq max > lock". Is it possible to change this frequency? I don't see this property > in the mega wizard. Ok, this was for Quartus, but looks like I can't specify it for Xilinx parts either, at least from what I've seen in the language templates. Maybe some of the Altera experts have an answer for Quartus? BTW: nice work for the latest Xilinx ISE 11.1. The GUI looks and feels better than the last version I have used some time ago. But would be nice to have something like the Mega Wizard in Quartus, or do I just not know where such a tool is located in the IDE? -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142132
Antti.Lukats@googlemail.com wrote: > ok, in light of the Virtex BRAM/ROM issue i see no way to use the AES3 > bitclock directly, that is the only possibility is to oversample the > clock > and use free running system clock to clock the BRAM's but this means > there is jitter in the AES3 clock, what is also bad Why is there jitter in this case? You are right that sometimes one system clock later or earlier the deserialized AES3 subframe is stored in the BRAM, if you use a system clock to clock the BRAM. This should be no problem for most applications. A deserializer can work with the external bitclock, but the data can be read with system clock (you have some time in the preamble to cross the clock domains). Another idea would be to use a dual port BRAM for the receiver: It is written by the deserializer with bitclock and read by the rest of the system with a system clock. Same for the transmitter. With this method only the realtime bitstream could be corrupted, but only if the clock is not valid anyway. The rest of the system is completly decoupled. Or using a FIFO for the clock domain crossing. Is this corruption problem on read really a "feature" of all FPGAs with BRAM from all vendors? -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142133
"BobW" <nimby_GIMME_SOME_SPAM@roadrunner.com> wrote:
>
>"Nico Coesel" <nico@puntnl.niks> wrote in message
>news:4a6acdbc.71573125@news.planet.nl...
>> "BobW" <nimby_GIMME_SOME_SPAM@roadrunner.com> wrote:
>>
>>>
>>>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in
>>>message
>>>news:ia1l6511mrt05k4vhifkcu1j9s1kc5i4nu@4ax.com...
>>>> On Fri, 24 Jul 2009 10:44:40 GMT, nico@puntnl.niks (Nico Coesel)
>>>> wrote:
>>>>
>>>>>John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>We want to use an XC3S1500 to talk to a single 16-wide 1 gbit DDR2
>>>>>>dram chip. The coregen thing seems to successfully build a dram
>>>>>>interface that's claimed to work up to 133 MHz. The DRAM is spec'd to
>>>>>>work down to 128 MHz, so there's a small overlap window. We'd run at
>>>>>>128.
>>>>>>
>>>>>>Our Xilinx FAE seems to be discouraging us from doing this, without
>>>>>>saying precisely why, suggesting some other parts. Spartan 6 would be
>>>>>>ideal (hard dram controller as I understand it) but are unavailable
>>>>>>for some vague time. We'd rather not use a new part for a single
>>>>>>project, since we will cut over to the s6's when they are available.
>>>>>>
>>>>>>Has anyone done DDR2 from a Spartan 3? Success/horror stories?
>>>>>
>>>>>I did a DDR design at 100MHz which shares a standard PC memory module
>>>>>(64 bit wide) between two Spartan 3 FPGAs (800MB/s per FPGA). I didn't
>>>>>like the MIG tool (way too big, ugly and too limited) so I rolled my
>>>>>own DDR controller. The trick is to get the sampling point for the
>>>>>incoming data right. I used a 90 degrees phase shifted capture clock
>>>>>that hit the sweet spot perfectly. I'm planning on upgrading this
>>>>>design to DDR2 using the speed grade 5 devices. I still have to do the
>>>>>math whether the phase shifted clock will work. There has to be a
>>>>>window in which the data is stable for the FPGA to sample it. If there
>>>>>is no such window a calibration scheme is required.
>>>>>
>>>>>I looked at the Spartan 6 FPGA but I doubt it will offer much
>>>>>improvement. The memory controller is still very limited when it comes
>>>>>to the amount of memory (width and address space) it can control.
>>>>
>>>> *Now* our Xilinx guy is saying, oops, the XC3S is fine to work with
>>>> DDR2. Maybe I'll add an external variable delay just in case we need
>>>> to tweak the read clock edge.
>>>>
>>>> John
>>>>
>>
>>>There are also techniques for stabilizing the write data and
>>>FPGA-generated
>>>RAM clock with respect to voltage, temperature, and unit-to-unit
>>>variations.
>>>This involves routing an output pin back to a clock input (IBUFG) and
>>>putting it in the DCM->BUFG feedback loop. I would assume that the Xilinx
>>>appnote does this (I think it does, iirc).
>>
>> IMHO this trick has no effect if you source the memory clock from the
>> FPGA, the delay variation in the IOB is cancelled when writing.
>> Writing data becomes a walk in the park.
>>
>
>That's right. Writing is always the easy part. When you generate the clock
>from the FPGA then that clock and data will always remain stable in relative
>phase.
>
>However, when you do this, the phase of the read data will now "drift" with
>respect to FPGA's internal clock. That's the problem.
>
>So, if you phase lock the output clock (and associated write data) by using
>the clock loop around technique then the read data will be locked, too.
More precisely: you'll get a clock that has the same phase shift as
the delay in the input path + output path + some clock routing delays
(ibufg, obugf). I'm not sure if all this results in a clock with less
uncertainty than just taking the worst case variations in the input
and output pads into account.
Besides, you'll need to re-clock the data into other flipflops
downstream. So a properly phase shifted clock which doesn't violate
setup and hold times is still required. The problem more or less
remains.
The Spartan 3 has regional clocks. On the top and bottom banks it is
possible to use DQS to clock the data into the IOB flipflops. There
are some severe routing contraints though (not well documented either)
which prohibits using the banks on the sides. You'll have to route
this part of the design first and get the pin assignment right before
making the PCB. This method also requires thourough analyses of where
the DQS is at to be able to clock the data into the downstream
flipflops.
It has been several years since I worked on the design but I clearly
remember that putting more 'helper' elements in series with signals
made things worse. Keeping things simple (clocking the data into a
known clock domain inside the IOB) resulted in a design which had the
best timing margins.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142134Peter, I posted: > > I have explained this aspect of the BRAM problem to Peter > repeatedly over the past few years, but he continues to claim > their "fix" is all that is needed. > And you replied: > > C'mon, let's not get nasty. > There was nothing remotely "nasty" about that sentence; it is a straightforward summary of the previous BRAM threads discussing this issue. Please stop attacking my posts without first understanding the actual problem that I am talking about. I have explained the painful impact of this 'feature' with respect to initialized BRAMs to you repeatedly over the past four years, with real world examples, yet you continue to post this claim of a "100% effective work-around". To wit: In the 2005 thread, I described the clock glitch problem: http://groups.google.com/group/comp.arch.fpga/msg/67b112027f71ade8 > > Or if the BlockROM clock is sourced by a DCM which goes > unlocked, thus rendering all BlockROM contents unreliable > until the device has been reconfigured. > Yet in 2007, you claimed to be unaware of the BRAM clock as a source of address setup violation: http://groups.google.com/group/comp.arch.fpga/msg/2a8c04584a96bc17 > > But I did not think about the DCM losing lock :-( > In that 2007 thread, I explained the various aspects of the external clock problem in painstaking detail: http://groups.google.com/group/comp.arch.fpga/msg/30bb0573b9468241 http://groups.google.com/group/comp.arch.fpga/msg/5f0d539d3c59131e http://groups.google.com/group/comp.arch.fpga/msg/a7723a92f8b90735 Now in 2009, you again make the same claim : > > I claim it has a solid work-around: > Enable the clock only when you are interested in the > read data output. > <snip> > I wish all problems had that good a work-around. > That is NOT a "good workaround" for many systems, because there is no possible way to create the 'psychic' enable logic. Once again: Modern PCB's are chock full of network/audio/video/ADC/DAC components providing external clock sources to the FPGA that can come and go without any advance warning. This corruption problem often makes initialized BRAMs unusable in those clock domains. Which is a real headache for those of us who have to design around this, and why I have previously suggested to you that the BRAM's need a bulletproof ROM mode. Even if such a mode added extra BRAM delay/latency, at least we could use BROMSs again in unpredictible clock domains. ----------------- PA> PA> It's just not obvious, and the FPGA vendors had to PA> make you aware of it. Which we did. PA> FPGA designers were aware of the symptoms ( multicycle reads trash BRAM data ) and fixed them ( re-clock multicycle address ) long before AR 21870 appeared to explain why. And as of 2009, AR 21870 still makes absolutely no mention of the need for caution with DCM startup or other clock transients, despite the fact that I made you aware of this problem in the 2005 and 2007 discussions on the newsgroup. ----------------- The following are specific examples from Xilinx app notes that are perhaps unusable because of this BRAM problem: ----------------- Self-Addressing FIFO Look at XAPP291, the "Self-Addressing FIFO" app note, which stores the next address in a portion of the BRAM. quoting from XAPP291 1.3: page 1 " " the self-addressing FIFO counters are implemented as " a ROM based sequencer inside the same memory being used " for data storage. " page 4 " " The self-addressing FIFO is a small and novel mechanism " for transferring data between clock domains while avoiding " the necessity of using a clock tree. " ... " This shows the ability to build multiple self-addressing " FIFOs, allowing designers to input or output data to external " devices without ever using the on-board global clock resources. " This is extremely useful in the design of many sorts of systems, " for example where interfaces to multiple external PHY devices " are required. " If you use this construct in the suggested application space, external clock domain crossings, what you have created is now a 'self-destructing FIFO' that can randomly trash the stored addresses in the initialized BRAM whenever the external clock exhibits any non-ideal behaviour. ----------------- SDI video clock recovery Look at figure 2-9, page 49, of XAPP514 4.0.1, in which an external CLC016 SDI CDR chip provides a clock to the FPGA. http://www.xilinx.com/support/documentation/application_notes/xapp514.pdf Then look at page figures 8-10 of the datasheet for that clock recovery chip, showing the timing of the carrier detect line relative to the clock entering/leaving the unknown state: http://www.national.com/ds/CL/CLC016.pdf Please explain to me how the FPGA could possibly know in advance that the clock recovery chip is about to lose lock because the video input is being switched or disconnected? BrianArticle: 142135
Has anyone benchmarked Core7 vs Core2 on NCverilog, Questa, Xilinx and Altera FPGA tools?Article: 142136
On Jul 26, 7:55=A0am, Brian Davis <brimda...@aol.com> wrote: > Peter, > > I posted: > > > > > I have explained this aspect of the BRAM problem to Peter > > repeatedly over the past few years, but he continues to claim > > their "fix" is all that is needed. > > And you replied: > > > > > C'mon, let's not get nasty. > > =A0There was nothing remotely "nasty" about that sentence; > it is a straightforward summary of the previous BRAM > threads discussing this issue. > > =A0Please stop attacking my posts without first understanding > the actual problem that I am talking about. > > =A0I have explained the painful impact of this 'feature' with > respect to initialized BRAMs to you repeatedly over the past > four years, with real world examples, yet you continue to post > this claim of a "100% effective work-around". > > =A0To wit: > > =A0In the 2005 thread, I described the clock glitch problem: > > http://groups.google.com/group/comp.arch.fpga/msg/67b112027f71ade8 > > > > > =A0Or if the BlockROM clock is sourced by a DCM which goes > > unlocked, thus rendering all BlockROM contents unreliable > > until the device has been reconfigured. > > =A0Yet in 2007, you claimed to be unaware of the BRAM clock > as a source of address setup violation: > > http://groups.google.com/group/comp.arch.fpga/msg/2a8c04584a96bc17 > > > > > =A0But I did not think about the DCM losing lock =A0:-( > > =A0In that 2007 thread, I explained the various aspects of the > external clock problem in painstaking detail: > > http://groups.google.com/group/comp.arch.fpga/msg/30bb0573b9468241http://= groups.google.com/group/comp.arch.fpga/msg/5f0d539d3c59131ehttp://groups.go= ogle.com/group/comp.arch.fpga/msg/a7723a92f8b90735 > > =A0Now in 2009, you again make the same claim : > > > > > I claim it has a solid work-around: > > Enable the clock only when you are interested in the > > read data output. > > <snip> > > I wish all problems had that good a work-around. > > =A0That is NOT a "good workaround" for many systems, because > there is no possible way to create the 'psychic' enable logic. > > =A0Once again: > > =A0Modern PCB's are chock full of network/audio/video/ADC/DAC > components providing external clock sources to the FPGA > that can come and go without any advance warning. > > =A0This corruption problem often makes initialized BRAMs > unusable in those clock domains. > > =A0Which is a real headache for those of us who have to > design around this, and why I have previously suggested > to you that the BRAM's need a bulletproof ROM mode. > > Even if such a mode added extra BRAM delay/latency, at least > we could use BROMSs again in unpredictible clock domains. > > ----------------- > PA> > PA> It's just not obvious, and the FPGA vendors had to > PA> make you aware of it. Which we did. > PA> > > =A0 FPGA designers were aware of the symptoms ( multicycle > reads trash BRAM data ) and fixed them ( re-clock multicycle > address ) long before AR 21870 =A0appeared to explain why. > > =A0And as of 2009, AR 21870 =A0still makes absolutely no mention > of the need for caution with DCM startup or other clock > transients, despite the fact that I made you aware of this > problem in the 2005 and 2007 discussions on the newsgroup. > > ----------------- > > The following are specific examples from Xilinx app notes > that are perhaps unusable because of this BRAM problem: > > ----------------- > Self-Addressing FIFO > > =A0Look at XAPP291, the "Self-Addressing FIFO" app note, > which stores the next address in a portion of the BRAM. > > quoting from XAPP291 1.3: > page 1 > " > " the self-addressing FIFO counters are implemented as > " a ROM based sequencer inside the same memory being used > " for data storage. > " > page 4 > " > " The self-addressing FIFO is a small and novel mechanism > " for transferring data between clock domains while avoiding > " the necessity of using a clock tree. > " ... > " This shows the ability to build multiple self-addressing > " FIFOs, allowing designers to input or output data to external > " devices without ever using the on-board global clock resources. > " This is extremely useful in the design of many sorts of systems, > " for example where interfaces to multiple external PHY devices > " are required. > " > =A0If you use this construct in the suggested application space, > external clock domain crossings, what you have created is now > a 'self-destructing FIFO' that can randomly trash the stored > addresses in the initialized BRAM whenever the external clock > exhibits any non-ideal behaviour. > > ----------------- > SDI video clock recovery > > =A0Look at figure 2-9, page 49, of XAPP514 4.0.1, in which > an external CLC016 SDI CDR chip provides a clock to the FPGA. > > http://www.xilinx.com/support/documentation/application_notes/xapp514... > > =A0Then look at page figures 8-10 of the datasheet for that > clock recovery chip, showing the timing of the carrier detect > line relative to the clock entering/leaving the unknown state: > > http://www.national.com/ds/CL/CLC016.pdf > > =A0Please explain to me how the FPGA could possibly know in > advance that the clock recovery chip is about to lose lock > because the video input is being switched or disconnected? > > Brian I am sorry if I offended anybody. I cannot solve every problem that I do not even fully understand. But I can explain (and have done so) the undesirable behavior of all BlockRMs, by Xilinx as well as Altera, when the address register goes metastable. Unfortunately, it is up to you, the user, to work around this problem. Double-synchronizing the address might be one solution. I suppose the fundamental cause will stay with us. Peter AlfkeArticle: 142137
On 26 Jul 2009 16:23:16 GMT, General Schvantzkoph <schvantzkoph@yahoo.com> wrote: >Has anyone benchmarked Core7 vs Core2 on NCverilog, Questa, Xilinx and >Altera FPGA tools? I'd also be very interested in Core7 vs Phenom II performance too (45nm AMD ie Phenom II 955 etc.) - Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 142138
On Jul 26, 3:18=A0am, Jaerder Sousa <jaer...@netcabo.pt> wrote: > Good Morning. > I want to get started on fpga development, but I cant decide on what > board and gate count to get. > I'm inclined tho the Xilinx spartan boards ( diligent BASYS or the > Nexys2 ) boards. > And linux compatibility for me is a must, since I use linux on my home > pc. > I'm planing to start on simple designs, so i prefer an inexpensive > solution, but well documented. > > I have a background on electronics and i'm currently studying C.S. > > Best Regards > > Jaerder Sousa. There's two ways to get inexpensive development boards. The first option, and probably a good one for you, is to get it through the school and the discounted University program of the FPGA vendor. The second way, which anyone can use, but may require some waiting, is to keep an eye out for the latest demo board for a recent FPGA product offering. These are generally offered with a deep discount, with the hope that the demo boards lead to part sales. For example Lattice recently announced the MachXO mini development kit at a $59 introductory price. Following the link to the Lattice site I can see the price has already been raised to $89. You get the idea. http://www.latticesemi.com/store/dev_kits.cfm?source=3Dlhma Regards, GaborArticle: 142139
Merrick1 is the first of a new board family for the high end ASIC prototype market and also for some of the more unusual processing applications. You can see the board loaded with it's 101 FPGAs fitted here http://www.enterpoint.co.uk/merrick/merrick1.html. I will have a board with me at DAC this week in San Francisco so come along our booth 4207 if you want to see the beast in the flesh. Monday entrance to DAC is free but does need a preregister on the DAC website. John Adair Enterpoint Ltd.Article: 142140
MikeWhy wrote: > The <project>.xise file serves the need, without exporting or importing. Looks like xml text file with all the files names and synthesis settings. This may be worth getting the license server working. -- Mike TreselerArticle: 142141
On Sun, 26 Jul 2009 13:42:25 -0700 (PDT), John Adair <g1@enterpoint.co.uk> wrote: >Merrick1 is the first of a new board family for the high end ASIC >prototype market and also for some of the more unusual processing >applications. You can see the board loaded with it's 101 FPGAs fitted >here http://www.enterpoint.co.uk/merrick/merrick1.html. > >I will have a board with me at DAC this week in San Francisco so come >along our booth 4207 if you want to see the beast in the flesh. > >Monday entrance to DAC is free but does need a preregister on the DAC >website. > >John Adair >Enterpoint Ltd. Yikes! How do you cool it? I saw somebody's logic simulator board at an Embedded Systems conf in SF a couple years ago. It had 64 big Virtex chips. The parts alone must have been over $100K. Are you coming all the way from the UK for the show? Bring your woolies: it's 58F and foggy at 4PM. Sunny California this ain't. JohnArticle: 142142
I also bring soemthing warm for SF when I come over. I noticed it wasn't warm in SF but our weather isn't too smart at home either this year. It's also not fantastic in New York where I am now either. Lets just blame it on global warming. Cooling is as big a problem on Merrick1 as with a Virtex board. It will run a light load with passive cooling. For a given performance level, and assuming both chips can do the point, the Spartan will usually bun less power. We are expecting for most ASIC prototyping applicatins that fans will be enough and we have a support frame planned for that..On the high performance computing there is going to be a trade between getting most out the array and the complexity of the cooling scheme. We are still at early days with this board so still learning on it and how far we can push it. There is a green arguement to the board. Depending on how well the FPGA array fits an application it will almost certainly beat most PCs and Virtex level boards to achieve the same result. We aren't going to talk about that much until our own stack is giving us some data and we get a better feel for it. We will be bring Virtex-6 products to market also for those that like ultimate performance. Possibly to the Merrick range and certainly in the Broaddown range of products and maybe a ouple of our other ranges. John Adair Enterpoint Ltd. On 27 July, 00:11, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Sun, 26 Jul 2009 13:42:25 -0700 (PDT), John Adair > > <g...@enterpoint.co.uk> wrote: > >Merrick1 is the first of a new board family for the high end ASIC > >prototype market and also for some of the more unusual processing > >applications. You can see the board loaded with it's 101 FPGAs fitted > >herehttp://www.enterpoint.co.uk/merrick/merrick1.html. > > >I will have a board with me at DAC this week in San Francisco so come > >along our booth 4207 if you want to see the beast in the flesh. > > >Monday entrance to DAC is free but does need a preregister on the DAC > >website. > > >John Adair > >Enterpoint Ltd. > > Yikes! How do you cool it? > > I saw somebody's logic simulator board at an Embedded Systems conf in > SF a couple years ago. It had 64 big Virtex chips. The parts alone > must have been over $100K. > > Are you coming all the way from the UK for the show? Bring your > woolies: it's 58F and foggy at 4PM. Sunny California this ain't. > > JohnArticle: 142143
Have a look at our range. There some projects around particularly for the RAGGEDSTONE1 board. Range is here http://www.enterpoint.co.uk/boardproducts.html. Some more shortly too. John Adair Enterpoint Ltd. On 26 July, 08:18, Jaerder Sousa <jaer...@netcabo.pt> wrote: > Good Morning. > I want to get started on fpga development, but I cant decide on what > board and gate count to get. > I'm inclined tho the Xilinx spartan boards ( diligent BASYS or the > Nexys2 ) boards. > And linux compatibility for me is a must, since I use linux on my home > pc. > I'm planing to start on simple designs, so i prefer an inexpensive > solution, but well documented. > > I have a background on electronics and i'm currently studying C.S. > > Best Regards > > Jaerder Sousa.Article: 142144
Hi, In psf_rm.pdf document (Xilinx EDK 9.02), there are some examples in section "Tri-state (InOut and Output) Signals". In the example under the title "Tri-state (In/Out) With Single-Bit Enable With Freely Named Ports" a mpd file is given as BEGIN tri_state_single OPTION IPTYPE=3DIP PARAMETER C_WIDTH=3D9, DT=3Dinteger PORT IPIO=3D=93=94, DIR=3DIO,VEC=3D[0:C_WIDTH-1],THREE_STATE=3DTRUE, TRI_= I=3DITRI, TRI_O=3DOTRI, TRI_T=3DTTRI PORT ITRI=3D=94=94, DIR=3DI, VEC=3D[0:C_WIDTH-1] PORT OTRI=3D=94=94, DIR=3DO, VEC=3D[0:C_WIDTH-1] PORT TTRI=3D=94=94, DIR=3DI END I noticed that PORT TTRI=3D"" DIR=3DI line has the direction marked as Input. Is it supposed to be O? Very same is done in the example following this one too. I couldn't find any example mpd file doing the same thing and assumed that this is a typo. Thanks for any help/directionArticle: 142145
On Jul 27, 5:08=A0am, Peter Alfke <al...@sbcglobal.net> wrote: > I am sorry if I offended anybody. I cannot solve every problem that I > do not even fully understand. > But I can explain (and have done so) the undesirable behavior of all > BlockRMs, by Xilinx as well as Altera, when the address register goes > metastable. > Unfortunately, it is up to you, the user, to work around this problem. > Double-synchronizing the address might be one solution. > I suppose the fundamental cause will stay with us. I'm puzzled how an address register going metastable can corrupt the contents of a Sync ROM. There is no write pathway, and the data is not 'moving about' - it is merely being read. Sure, the data for a violating clock-cycle will be undefined, but how exactly does the memory content itself become corrupted ? That requires a write line to be active ?. (which is what I understand is the 'fish hook' here ?) -jgArticle: 142146
"bishopg" <bishopg12@gmail.com> wrote in message news:557b39ef-b190-43db-8ad7-a460aa4e685d@c1g2000yqi.googlegroups.com... >I am currently working on a design using the v4fx20. My current > design consists of bram memory at 0xffff0000 to 0xffffffff and DDR at > 0x00000000 to 0x03ffffff. I can read and write from the bram memory, > but whenever I either read or write from anywhere within the DDR > memory space, my entire memory space (0x00000000 - 0xffffffff) becomes > unusable. Which MPMC version? How is the BRAM connected? Can you read/write your DDRAM successfully if you don't touch the BRAM? /MikhailArticle: 142147
Seems to be a description of a tri-state buffer. TTRI is just an enable pin of the buffer, so it should be an input. /Mikhail "monurlu" <monurlu@gmail.com> wrote in message news:bb0754fa-0a90-4e5c-8a40-a36987b65c42@t13g2000yqt.googlegroups.com... Hi, In psf_rm.pdf document (Xilinx EDK 9.02), there are some examples in section "Tri-state (InOut and Output) Signals". In the example under the title "Tri-state (In/Out) With Single-Bit Enable With Freely Named Ports" a mpd file is given as BEGIN tri_state_single OPTION IPTYPE=IP PARAMETER C_WIDTH=9, DT=integer PORT IPIO=“”, DIR=IO,VEC=[0:C_WIDTH-1],THREE_STATE=TRUE, TRI_I=ITRI, TRI_O=OTRI, TRI_T=TTRI PORT ITRI=””, DIR=I, VEC=[0:C_WIDTH-1] PORT OTRI=””, DIR=O, VEC=[0:C_WIDTH-1] PORT TTRI=””, DIR=I END I noticed that PORT TTRI="" DIR=I line has the direction marked as Input. Is it supposed to be O? Very same is done in the example following this one too. I couldn't find any example mpd file doing the same thing and assumed that this is a typo. Thanks for any help/directionArticle: 142148
Andy wrote: > For example, if you gate all the interface signals to a module with a > generic/constant, the synthesis tool will not implement one gate/flop > of it (leave the clock and reset alone, they'll go away by themselves). Gee, that's quite efficient from a coding POV, and makes it much more readable too! (Not) Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 142149
On Jul 24, 12:21=A0am, bishopg <bishop...@gmail.com> wrote: > I am currently working on a design using the v4fx20. =A0My current > design consists of bram memory at 0xffff0000 to 0xffffffff and DDR at > 0x00000000 to 0x03ffffff. =A0I can read and write from the bram memory, > but whenever I either read or write from anywhere within the DDR > memory space, my entire memory space (0x00000000 - 0xffffffff) becomes > unusable. =A0For example: > > XMD% mrd 0xffffff00 16 > FFFFFF00: 00000000 > FFFFFF04: 00000000 > FFFFFF08: 00000000 > FFFFFF0C: 00000000 > FFFFFF10: 00000000 > FFFFFF14: 00000000 > FFFFFF18: 00000000 > FFFFFF1C: 00000000 > FFFFFF20: 00000000 > FFFFFF24: 00000000 > FFFFFF28: 00000000 > FFFFFF2C: 00000000 > FFFFFF30: 00000000 > FFFFFF34: 00000000 > FFFFFF38: 00000000 > FFFFFF3C: 00000000 > > XMD% mwr 0xffffff00 0x12345678 > XMD% mrd 0xffffff00 16 > FFFFFF00: 12345678 > FFFFFF04: 00000000 > FFFFFF08: 00000000 > FFFFFF0C: 00000000 > FFFFFF10: 00000000 > FFFFFF14: 00000000 > FFFFFF18: 00000000 > FFFFFF1C: 00000000 > FFFFFF20: 00000000 > FFFFFF24: 00000000 > FFFFFF28: 00000000 > FFFFFF2C: 00000000 > FFFFFF30: 00000000 > FFFFFF34: 00000000 > FFFFFF38: 00000000 > FFFFFF3C: 00000000 > > XMD% mrd 0x00000000 16 > 0: FFFFFFF8 > 4: FFFFFFF8 > 8: FFFFFFF8 > C: FFFFFFF8 > 10: FFFFFFF8 > 14: FFFFFFF8 > 18: FFFFFFF8 > 1C: FFFFFFF8 > 20: FFFFFFF8 > 24: FFFFFFF8 > 28: FFFFFFF8 > 2C: FFFFFFF8 > 30: FFFFFFF8 > 34: FFFFFFF8 > 38: FFFFFFF8 > 3C: FFFFFFF8 > > XMD% mrd 0xffffff00 16 > FFFFFF00: FFFF0958 > FFFFFF04: FFFF0958 > FFFFFF08: FFFF0958 > FFFFFF0C: FFFF0958 > FFFFFF10: FFFF0958 > FFFFFF14: FFFF0958 > FFFFFF18: FFFF0958 > FFFFFF1C: FFFF0958 > FFFFFF20: FFFF0958 > FFFFFF24: FFFF0958 > FFFFFF28: FFFF0958 > FFFFFF2C: FFFF0958 > FFFFFF30: FFFF0958 > FFFFFF34: FFFF0958 > FFFFFF38: FFFF0958 > FFFFFF3C: FFFF0958 > > To me this sounds like a timing issue, but I believe I have everything > constrained that needs to be constrained. =A0It could also be a > initialization issue but I'm not sure. =A0Has anyone run into such an > issue? MPMC memory is not working, it will lock up the bus on first access to it its a known "feature" Antti
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