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
For those of you that were desperate for Raggedstone1 brackets we finally have them in stock. They won't show as stock on the shop website for a week or so due to staff holidays but we do have a lot of them available so contact us on our board sales email if you need one in a hurry. Apologies for the delay in having these available but we got caught out again by demand of the Raggedstone1 + bracket. To improve our mechanical supply issues we have added to our manufacturing operation a limited mechanical processing capability for producing brackets and small metalwork as part of what we now do. As a side benefit of this we can for OEM customers we can now produce fairly small run custom brackets for any of our PCI / PCI-E boards etc. at what we consider a reasonable cost. John Adair Enterpoint Ltd.Article: 120201
"Tommy Thorn" <tommy.thorn@gmail.com> wrote in message news:1180762018.504484.139350@i38g2000prf.googlegroups.com... > On Jun 1, 6:38 pm, Marlboro <cco...@netscape.net> wrote: >> A memory block has been told having "read latency of 3", assume the >> read pointer has been reset >> >> How many read clocks does it take to read out the first 10 bytes? > > As many as it has too, gosh!! > > Tommy (applogies to Napoleon) > I thought the answer to pop quizzes was to 'shoot the hostage'? i.e. Jeff Daniels? Whatever, don't let the answer be below 50 or the memory will blow up. Syms.Article: 120202
"Pasacco" <pasacco@gmail.com> wrote in message news:1180790373.677725.6920@q66g2000hsg.googlegroups.com... > > I am not finding a way to implement "Asynchronous READ" in BRAM. > The bodgers way to do this is to use the falling edge of the clock on the read section. Nasty though! HTH, Syms.Article: 120203
On Sat, 02 Jun 2007 08:45:17 -0700, austin <austin@xilinx.com> wrote: >Test01, > >PCB layout will be a real challenge, as you will need to make all traces >the same length (including the traces in the package to the die). Where do you find the package internal trace lengths documented, so that you can allow for them in your PCB trace length calculations? Answer Record 18078 says http://www.xilinx.com/xlnx/xil_ans_display.jsp?iCountryID=1&iLanguageID=1&getPagePath=18078&BV_SessionID=@@@@1060307370.1180870386@@@@&BV_EngineID=ccchaddklgmehljcefeceihdffhdfkf.0 with respect to the common FG or BG packages, "since these package structures do not lend themselves to this kind of analysis, Xilinx does not have this information available." For other packages it refers to AR15321, where you find that for Virtex-II era devices (in unspecified packages) the information IS available but you have to open a webcase to get it. - BrianArticle: 120204
On Jun 3, 6:20 am, "Symon" <symon_bre...@hotmail.com> wrote: > "Pasacco" <pasa...@gmail.com> wrote in message > > news:1180790373.677725.6920@q66g2000hsg.googlegroups.com... > > > I am not finding a way to implement "Asynchronous READ" in BRAM. > > The bodgers way to do this is to use the falling edge of the clock on the > read section. Nasty though! > HTH, Syms. If there's clock in the FIFO output domain, just don't see why he needs Async read ??? Don't let me guess it correct, the reason he wanna do this because there's no read clock at all. If that's true, another nasty way to do this is to generate a "glitch" from any changing in the address bits. Make sure it meets the BRAM setup time then the glitch can be used as the read clockArticle: 120205
"Microcontrollers have a better predictable time behaviour, because their circuit is integrated in silicon and is unchangeable; unlike FPGAs which have variable timing performances." Is this statement correct? JidanArticle: 120206
<jidan1@hotmail.com> wrote in message news:1180877736.514050.260890@g4g2000hsf.googlegroups.com... > "Microcontrollers have a better predictable time behaviour, because > their circuit is integrated in silicon and is unchangeable; unlike > FPGAs which have variable timing performances." > > Is this statement correct? > > Jidan > Jidan, If you're gonna post your homework questions, please do us the courtesy of posting from somewhere else other than tuwien.ac.at. Thanks, Symon.Article: 120207
jidan1@hotmail.com wrote: > "Microcontrollers have a better predictable time behaviour, because > their circuit is integrated in silicon and is unchangeable; unlike > FPGAs which have variable timing performances." > > Is this statement correct? Of course : One is Hard, and one is Soft, how can something that is soft have "a better predictable time behaviour" ? You can find other examples to prove this in the data sheets too: Look at the uC with 1-2% OnChipOsc Specs, and then look for any tolerance specs on the FPGA on chip Osc. Again, uC clearly have "a better predictable time behaviour". You should win this debate easily. -jgArticle: 120208
Marlboro wrote: > On Jun 3, 6:20 am, "Symon" <symon_bre...@hotmail.com> wrote: >> "Pasacco" <pasa...@gmail.com> wrote in message >> >> news:1180790373.677725.6920@q66g2000hsg.googlegroups.com... >> >>> I am not finding a way to implement "Asynchronous READ" in BRAM. >> The bodgers way to do this is to use the falling edge of the clock on the >> read section. Nasty though! >> HTH, Syms. > > If there's clock in the FIFO output domain, just don't see why he > needs Async read ??? > By "Async read", he means that he doesn't want to wait one clock after applying the read address before getting the data out.Article: 120209
Brian, Thanks for sharing this information. Certiainly when doing the PCB layout, we will need to take the internal trace length of high speed (800Mbps) signals.Article: 120210
On Mon, 04 Jun 2007 03:15:14 +1200, Jim Granville <no.spam@designtools.maps.co.nz> wrote: > >Again, uC clearly have "a better predictable time behaviour". > >You should win this debate easily. > >-jg Please don't feed the monkeys. They're getting a balanced diet from the zoo-keeper already.Article: 120211
In news:4662dab4$1@clear.net.nz timestamped Mon, 04 Jun 2007 03:15:14
+1200, Jim Granville <no.spam@designtools.maps.co.nz> posted:
"jidan1@hotmail.com wrote:
> "Microcontrollers have a better predictable time behaviour, because
> their circuit is integrated in silicon and is unchangeable; unlike
> FPGAs which have variable timing performances."
>
> Is this statement correct?
Of course : One is Hard, and one is Soft, how can something
that is soft have "a better predictable time behaviour" ?
You can find other examples to prove this in the data sheets too:
Look at the uC with 1-2% OnChipOsc Specs, and then look
for any tolerance specs on the FPGA on chip Osc.
Again, uC clearly have "a better predictable time behaviour".
You should win this debate easily."
Though not necessarily about microcontrollers, it was argued that
newer processors are less predictable than FPGAs in M. Ward;
N. C. Audsley, "Hardware Compilation of Sequential Ada", CASES 2001.
Article: 120212jidan1@hotmail.com schrieb: > "Microcontrollers have a better predictable time behaviour, because > their circuit is integrated in silicon and is unchangeable; unlike > FPGAs which have variable timing performances." > > Is this statement correct? You could also try to compare a house with bricks. Yes, you can build a house out of bricks (but also out of something else, like timber). And yes - if bricks are fixed to a structure, that we call a house you can compare it with a house made of timber - or even with a brick-wall. A FPGA is like bricks and a microcontroller is like a house in this comparison. RalfArticle: 120213
> ERROR:NgdBuild:924 - input pad net 'myclk' is driving non-buffer > primitives: > pin C on block my_user_command_register_1 with type FDE, I think it looks like your clock input it directly connected from the input pad to logic. You need to first connect it to some type of global clock buffer or other clock resource before using it in the fabric. And it looks like you have placed constraints incorrectly for the led_error_output. It should be an ouput signal at your top level. Then the syntax in the UCF is: NET "led_error_output" LOC = "whatever" | IOSTANDARD = "whatever" ;Article: 120214
I just found the Serial Flash Loader (SFL) which allows you to program an Active Serial (AS) part (EPCSx) using the JTAG port, sparing you the need for a dedicated serial config header. According to AN370: http://www.altera.com/literature/an/an370.pdf this is made possible by a megawizard function which can be in your design or a stub design which is loaded expressly for doing the update. The programming tool in Quartus recognizes the "JIC" files and selects a "factory default SFL image" to accomplish the loading. There are two rows and thus two "program" checkboxes, and I assumed you could simply un-check the FPGA part if you included SFL in your design, but the boxes are locked together. What is the trick for using the SFL embedded in your design instead of "factory default SFL image"? -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 120215
we are making bram controller which takes instruction from microblaze processor.we have to write a c program giving read and write request to bram controller.could anyone can tell us a way to synchronize our instruction with clock pulse ?Article: 120216
On Sun, 03 Jun 2007 06:35:36 -0700, jidan1@hotmail.com wrote: >"Microcontrollers have a better predictable time behaviour, because >their circuit is integrated in silicon and is unchangeable; unlike >FPGAs which have variable timing performances." > >Is this statement correct? I don't know, because it's nearly meaningless. What I *do* know is this: Once you've successfully implemented a given function or circuit on an FPGA, its timing is entirely predictable in the sense that every copy of that FPGA will meet the same timing spec - maximum clock frequency, input setup time, output delay, etc. In a rather similar way, every microprocessor chip of the same type that you buy will meet its data sheet timing spec. So in that sense, the statement is nonsense because FPGA implementations and microprocessors are equally predictable at meeting their timing specs. I also know that a typical microcontroller represents a large investment in design and verification work by the manufacturer, work that I would have to do myself if I wished to implement exactly that microcontroller in an FPGA. So I'm not going to bother to do that. I'll buy the uC chip, thanks - unless the uC function can be trivially integrated into my FPGA using the nice system-builder tools currently on offer. I also know that I can design things in an FPGA that will outrun a microcontroller by many orders of magnitude in speed. And here we perhaps get to the nub of your statement, because until I embark on the FPGA design I can't know exactly how fast it will run - what its Fmax will be. In that sense, and only in that sense, the FPGA is "unpredictable". However, modern timing analysis tools, combined with my own engineering intuition about which parts of the design are most likely to be timing-critical, will quickly lead me to a good estimate of the speed that I will ultimately achieve, and therefore will guide my design strategy so that I can meet my application's requirements. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 120217
Marlboro <ccon67@netscape.net> writes: > A memory block has been told having "read latency of 3", assume the > read pointer has been reset > > How many read clocks does it take to read out the first 10 bytes? How long is a piece of string? Your posting is missing key details of the problem. If you want us to do your homework for you, you'll have to do a better job of typing in the problem. Note that free homework answers are worth as much as you pay for them, as an upper bound. They may be worth even less.Article: 120218
Hello everybody, I am trying to interface my user logic ip_inv through the OPB in EDK using a register like this: the c code in my test_application to access the ipcore is : IP_INV_mWriteReg(0x00000010, 0, read_val); read_val2=IP_INV_mReadReg(0x00000010, 0); My user logic is just a not operation. How do we make sure that the value is written from the IPIF register into the user logic and then back to the IPIF register ? I am expecting a inverted value in "read_value2" but I am getting the same value as "read_value". Thanks, KOustavArticle: 120219
Adnan wrote: > Now the problem is that sata controllers successfully reads all the > data from memory and transfer it to hard disk but once its writes data > back to sram I get mismatches. I have used chipscope pro and I confirm > that signal terminates properly with exact expected data on PCI bus > but once wishbone master module outputs address and data it contains > few errors. Can you help me with this. Are you sure the timing on the SRAM controller in your FPGA is correct? You need to account for register-to-pin and pin-to-register delays when calculating the SRAM read/write cycle times. As well as considering tco you need to put constraints on the aforementioned delays and factor them into your timing... 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: 120220
Ben Jackson wrote: > The programming tool in Quartus recognizes the "JIC" files and selects > a "factory default SFL image" to accomplish the loading. There are two > rows and thus two "program" checkboxes, and I assumed you could simply > un-check the FPGA part if you included SFL in your design, but the > boxes are locked together. > > What is the trick for using the SFL embedded in your design instead of > "factory default SFL image"? What you see is exactly what you want. It works for me. I assume the 'factory default SFL image' is simply a 'bootstrap' image for programming SFL. BTW once you've programmed your JIC image you need to power-cycle your board. Your custom FPGA image should then be configured as usual whilst allowing subsequent JIC programming. 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: 120221
Mark McDougall wrote: I should clarify - you simply need to instantiate the SFL mega-function in your design. Once you've built your image, use Convert Programming Files to produce a .JIC file which includes your .SOF. You can then program the FPGA via JTAG with your new .SOF, then re-program with the .JIC which configures your EPCS device. Then power-cycle your board. Subsequent updates require reproducing the JIC from the SOF and re-configuring with the JIC. 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: 120222
Hi folks, I am desperately trying to load a design via System ACE onto a ML403 board. What I use: ISE 8.2i ML403 Linux What I did: Synthesized a very small design (some led blinking). Then generated System ACE with my .bit file. Added my bitstream to all config addresses. I formatted the CF dos partition with: mkdosfs -s 64 -F 16 -R /dev/sda1 - using the original partition table that came on the card. Mounted with -ofat=16 - also tried without Now I tried to move all generated files to the CF -> Red light Picked .ace file and used as standalone system.ace -> Red light Copied the original contents of the DOS partition into the CF (by copy, not the image!!) -> Green light Copied my .ace file into the designated position for an own ace -> Green light, after selection from the menu -> Red light Copied bootloader .ace file from the original image as system.ace into my CF -> Green light So I think that my DOS FS generation is ok as I can make a working CF. But my .ace file doesn't seem to work. I have tried all that several times, thinking over and over and over again. My bitfile works when I upload it directly via JTAG. Has anyone an idea what I have done wrong? I don't have any further ideas. Thank you all very much!!! Best regards, Philipp :-)Article: 120223
I have a project where I am trying to use modular design flow. When I do synthesis of one of my modules I see the message in the log. Number of TBUFs: 61 out of 0 (*) I think this is causing me problems when I try to do the assemble, because those modules get dropped from the design. Any suggestions on what I am doing wrong or how to work around it.Article: 120224
You will need to select the device type in coregen as a spartan IIE, generate the core, and use the resulting .edn netlist in your S3 design. CICs use basic, non-device specific primitives (adders, counters, registers etc ....). When I first ported my first DSP FPGA from a SIIE to S3 two years ago, there was a moment of panic when I saw CICs were not supported. I think this is just a deficiency in the GUI that has never been resolved. -- Regards, John Retta Owner and Designer Retta Technical Consulting Inc. email : jretta@rtc-inc.com web : www.rtc-inc.com <cs_posting@hotmail.com> wrote in message news:1180536814.626509.110470@p47g2000hsd.googlegroups.com... > Does anyone know if the Xilinx CIC core will work in the Spartan 3? > It's not listed as a target (only Spartan IIE) but then the data sheet > is dated 2002, wheras S3 apparently was announced in 2003... >
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