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
Let me elaborate a bit more. My understanding: False Paths: Paths that are not timming critical but show up in the timming report with a -ve slack. Can't think of an example. multi-cycle paths : Paths which can take 2 or more cycle to complete. But this would mean you gate the clock of the output/second resgiter in a multi cycle path so that it resgisters the right input after x clock cycles. Wouldn't that violate the sync design rules byt gating the clock and thus introducing skew? Aren't you better off pipelining it anyway, so that you get a result after every clock cycle after the inital pipeline latency.Article: 90601
Jim, you wrote: "Interesting - so for sustained thru-put on these, you are best to avoid going empty, which probably means two operating modes : fastest, and clean-out-the-last-byte(s)" I don't get it. Are you referring to the fact that you effectively lose a few read clock cycles after having gone EMPTY? Why would that be a problem? I think it helps the state of the FIFO, so that it does not go empty so often.... Although that is no problem, as demonstarated by our 200MHz/500 MHz test. I do not see any problem. You seem to. Let me know the reason. Peter AlfkeArticle: 90602
Spartan is much cheaper and does not have all the bells and whistles of Virtex. So you have to knit your own, or grab a core. Complexity depends on synchronous/asynchronous choice, and on max clock rate. At a slow speed, you can time share read and write. Many choices... Peter AlfkeArticle: 90603
Peter Alfke wrote: > Jim, you wrote: > "Interesting - so for sustained thru-put on these, you are best to > avoid > going empty, which probably means two operating modes : fastest, and > clean-out-the-last-byte(s)" > > I don't get it. Are you referring to the fact that you effectively lose > a few read clock cycles after having gone EMPTY? Why would that be a > problem? I think it helps the state of the FIFO, so that it does not go > empty so often.... > Although that is no problem, as demonstarated by our 200MHz/500 MHz > test. > > I do not see any problem. You seem to. Let me know the reason. Now I have to think carefully.... You are right, that going empty infers spare capacity, but I was looking at it as extra channel latency, and tend to be averse to any extra latency. Such latency only happens on EMPTY, and the effect is to make the FIFO slightly more full next time, which tends to then avoid the latency... so it is self correcting, and FIFOs are by nature elastic. If you were using the FIFO for rate smoothing, then the latency could be a gotcha, as it introduces a step-pause in the delivery ? -jgArticle: 90604
Hi, I am driving a LCD display with a pixel clock of 66 MHz. The pixels are stored in a fifo, for parallel to lvds conversion I use an external IC, because my Virtex2 has a to small speed grade to do lvds directly. I generate my pixel_clk with a dcm. Then I have lvds_clk <= not pixel_clk; lvds_ram_clk <= pixel_clk; lvds_clk goes to the parallel to lvds converter IC and lvds_ram_clk to the fifo that contains the pixel data. The pixel fifo takes its clock signal at rising edge. I have a process where I set up my lcd control signals process (pixel_clk,screen_reset) begin if screen_reset='1' then .... elsif rising_edge(pixel_clk) then .... the process sets up the control signals on the rising edge. I think with this setup all the data should be ready at the falling edge. The problem is now, that the par->lvds IC needs the data 2.5 ns before falling edge (setup time) and 0.5 ns afterwards (hold time). My constraints look like this: NET "clk" TNM_NET = "clk"; -- clk goes into the dcm TIMESPEC "TS_clk" = PERIOD "clk" 10 ns HIGH 50 %; NET "pixel_clk" TNM_NET = "pixel_clk"; -- comes out of the dcm, TIMESPEC "TS_pixel_clk" = PERIOD "pixel_clk" 10 ns HIGH 50 %; -- pixel_clk = clk / 1.5 I think this is not enough to fulfill the timing requirements. Can somebody help me? My display flickers a little bit, I am not sure where it originates from, timing issues or bad HF cable/circuit layout. regards, BenjaminArticle: 90605
If you are emptying slightly faster than you fill it, you will go empty (sooner or later). The penalty is then that you loose not one clock tick,but perhaps three. That will delay the next going empty longer than it would be if you had lost only one clock tick. if you are concerned, you can run against ALMOST EMPTY and "voluntarily" sacrifice one single clock tick. Whatever you do, you cannot read out more than you put in . :-) PeterArticle: 90606
Hi, I'm working with the Virtex-II Pro FPGA. Is there a way that we can run VHDL code for FPGA in PowerPC405 cores? So far I've only seen documents on embedded designs using EDK or FPGA programming using ISE. I'll appreciate any references or tips. Thanks. EricArticle: 90607
You are running at 66 MHz, and you think Virtex2 is too slow? Are you kidding? Did you ever use the fine phase adjust capability in the DCM, where you can move the clock in 256 increments? Peter AlfkeArticle: 90608
>> In principle there is nothing that prevents the synthesis tools to
>> execute processes that are only activated once to determine the
>> result.
>
> I agree to that.
> As long as we are discussing the above problem of initializing RAMS/ROMS
> from files this would be a nice feature for the next VHDL Standard.
You can already to this in synthesizable VHDL using functions. The
difficulties come in from trying to read data from a file, and when
working with real numbers. Both of these already exist in VHDL. The
problem isn't a VHDL standards problem, rather it is due to the
synthesis tools not recognizing the functions in stdio/textio and
math_real. This is understandable since neither are synthesizable, but
they could in principle be allowed in functions only for sythesizable
code...ie for generation of constants. I do recall a while back that
synplicity indicated that they would start allowing reals for developing
constants. I don't know that it actually came to pass, as I haven't
tried that in a number of years, as it is not generally recognized by
simulators. If you want this capability to be supported in your tools,
then let the synthesizer vendors know your wishes. This doesn't require
any changes to VHDL as a language or any new constructs, just limited
added support in the synthesis tools to allow file i/o and computation
using reals in a limited set of circumstances (ie, in functions where
the computation or file read results in constants).
--
--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: 90609On 17 Oct 2005 14:18:54 GMT, kd (pingboypulsar<spamoff>@hotmail.com) wrote: >Thanks! > >Yeah the problem is im a chemical engineer doing research with very >basic electronic engineering knowledge. You brought your question to the FPGA news group, and sure enough everyone is trying to help you on the issue of connecting ADCs to FPGAs. Let me try kicking you in a different direction, just in case it makes more sense :-) >I need a kick in the right direction. There is alot of stuff out >there, i just need to figure out the right path. Current help and >more is very much appreciated! Ok, here goes: Why are you trying to do this with an FPGA ??? In my experience, when people in other engineering/science fields of endeavor want to do data acq (ADC/DAC) it is usually part of some sort of experiment or process control. It is not the development of a new custom instrument. What you typically want to do is gather data from your sensors, and then process it to get to some result (maybe process control info, or maybe a graph in a powerpoint presentation, or maybe an Excel spread sheet). Your wrote: >Basically its for industrial sensors, like thermocouples, >0-10v, -5v-5v, 0-5v, 0-20ma, 4-20ma sensors. which screams out that this is where you are headed (but I could be wrong :-) If you are trying to build a custom, self contained ACQ system, then going out and buying chips (ADC, DAC, FPGA) may be the way you have to go. But, if the collected data is to processed on a "standard" PC, then you can save a huge amount of pain and suffering by just going out and buying a data acq board that plugs into your computer, or that connects to the computer over ethernet, or serial (rs232), or USB. Look at products from: National Instruments: http://www.ni.com/ Data Translation: http://www.datatranslation.com/ IO Tech: http://www.iotech.com/index.html Omega: http://www.omega.com/prodinfo/dataacquisition.html Measurement Computing: http://www.measurementcomputing.com/ Dataq Instruments: http://www.dataq.com Get started at $25 http://www.dataq.com/194.htm >Cheers! All the best, Philip Freidin Philip Freidin FliptronicsArticle: 90610
Peter Alfke schrieb: > You are running at 66 MHz, and you think Virtex2 is too slow? Are you > kidding? > Did you ever use the fine phase adjust capability in the DCM, where you > can move the clock in 256 increments? > Peter Alfke > Hi Peter, the lvds clock is 7*clk. I want to run at 85 MHz in the end, that would be 595 MHz. regards, BenjaminArticle: 90611
Kunal wrote: > Aren't you better off pipelining it anyway Yes, if you can make timing that way, it's less trouble. The pipeline requires no special constraints. Multicycle does. http://groups.google.com/groups?q=fpga+false+path+multicycle -- Mike TreselerArticle: 90612
Kunal wrote: > Let me elaborate a bit more. > My understanding: > > False Paths: Paths that are not timming critical but show up in the > timming report with a -ve slack. Can't think of an example. > > multi-cycle paths : Paths which can take 2 or more cycle to complete. > But this would mean you gate the clock of the output/second resgiter in > a multi cycle path so that it resgisters the right input after x clock > cycles. Wouldn't that violate the sync design rules byt gating the > clock and thus introducing skew? Aren't you better off pipelining it > anyway, so that you get a result after every clock cycle after the > inital pipeline latency. Or use a clock enable. False paths are paths that you (as the designer) know aren't timing critical. (Such as a an output pin clocked on a 50 Mhz clock that drives an led). Multicycle paths are paths that you (as the designer) know are allowed to take multiple cycles to resolve. For instance, if you have a section of logic running off a 100Mhz clock, but clock enables running to every flip-flop in that section of logic, then you know that every signal has two cycles to resolve before it will be sampled by the next stage. JeremyArticle: 90613
Hey Ben, Wherever I see "Falling edge" I worry! So, try making the Rising edge of 'pixel clock' your global data clock within the device. Shun that F-word. Make sure that everything you send outside the FPGA comes from a FF in an IOB clocked by the Rising edge of this clock. This includes the clock you're sending out. Search cyberspace for "clocks DDR". You can use the DDR magic in the IOB to copy the clock out in perfect synchronicity with your data. (Well, at 66MHz, perfect!) The DDR circuit absolves you of the F-ing word evil! Cheers Syms.Article: 90614
Hey Kunal, So, I have two questions. A) If you're posting from Xilinx's IP address, why not ask the local populace? B) How did you hack into Xilinx's server to post? C) Why can I neither count or use a touchpad without multi-posting? Cheers, Syms. ;-) "Kunal" <kunal.shenoy@gmail.com> wrote in message news:1129583827.348591.276200@g43g2000cwa.googlegroups.com... > Let me elaborate a bit more. > My understanding: > > False Paths: Paths that are not timming critical but show up in the > timming report with a -ve slack. Can't think of an example. > > multi-cycle paths : Paths which can take 2 or more cycle to complete. > But this would mean you gate the clock of the output/second resgiter in > a multi cycle path so that it resgisters the right input after x clock > cycles. Wouldn't that violate the sync design rules byt gating the > clock and thus introducing skew? Aren't you better off pipelining it > anyway, so that you get a result after every clock cycle after the > inital pipeline latency. >Article: 90615
Hello CMOS, Sadly, I've spent the last fortnight following your advice. http://tinyurl.com/76ovq Trouble is, my eyesight has been badly affected. Could you post in a bigger font? That would.... omigod, what's s/he going to do with THAT? Cheers, Syms. p.s. So, normally from an FPGA clock is an output, try searching for OBUF in the libraries guide. Data is bi-directional (like a large percentage of the folks on those sites you recommended) so look for OBUFT and IBUF. ;-) "CMOS" <manusha@millenniumit.com> wrote in message news:1129562457.464856.260830@g43g2000cwa.googlegroups.com... > hi, > im trying to use i2c open source core available from opensorces.org and > having problems with cofiguring the "scl" and "sda" from the top level > design with the use of IO buffers. if anyone got experience on how to > correctly configure these two ports from a top level hierachy, pls let > me know. > > thank you. > CMOS >Article: 90616
You can't count?Article: 90617
I said that in my post. Twice! "Luke" <lvalenty@gmail.com> wrote in message news:1129592997.709631.130560@g43g2000cwa.googlegroups.com... > You can't count? >Article: 90618
I thought it would a good discussion to have on the FPGA group, rather than me asking experts and keeping it to myself. I am sure others new to FPGA design will have the same questions as well. It would be nice for a generic discussion to show up if someone typed 'FPGA timing' into the search box, that is if I didnt SPELL the topic wrong ! :-)Article: 90619
..and, you cheeky bugger, posting from Intel.com is not a good idea if you're slagging off people's arithmetic! ;-) http://www.maa.org/mathland/mathland_5_12.html Cheers, Syms. "Luke" <lvalenty@gmail.com> wrote in message news:1129592997.709631.130560@g43g2000cwa.googlegroups.com... > You can't count? >Article: 90620
I read this thread about initializing FPGA memory with some interest. Well over a year ago, I asked the XST developers in Grenoble to add support for File I/O during VHDL elaboration. This actually works in ISE 7.1! You can write a VHDL function that opens a file (using the TextIO package), reads data out of it, and returns an array that can be used to initialize a signal array that has memory inferred on it. You can also write files, if you feel like you have a need for it. I argued that there exists a subclass of File I/O operations that can fit into the model of constant propagations that occur during elaboration. I've used this to write a VHDL function that will read an Intel MCS file into a ram array initial value during synthesis. In principal, anything you can parse in VHDL is fair game, although in practice, I've found the file IO a little fragile, especially when dealing with access types. Read the XST documentation to see how it's done. I have various nefarious plans for this capability, particularly in the area of automatically iterated code that refashions the circuit topology to deal with the timing failures found on the previous iteration. Bottom line... you can read and write files during VHDL synthesis with XST. I've heard some talk about Verilog 2001 being used for much the same thing, but don't know if it works yet. I'm not satisfied with synthesis File I/O in VHDL... I'd much rather have the ability in VHDL to control synthesis iteration on sub-components that fail to meet timing. But that's an argument I'm saving for the VHDL-200X committee. JohnArticle: 90621
On Mon, 17 Oct 2005 12:32:48 -0700, Dave Pollum wrote: > Peter Alfke wrote: >> Let me correct this: >> The addressing depth of Virtex-4 FIFOs is 512, 1024, 2048, or 4096 >> locations. The word "byte" is meaningful only for the 2048 x 9 >> configuration. >> The FULL flag goes active one write clock cycle after the FIFO has been >> filled. That means, in a continuous write situation, the last written >> entry will be lost. That's why I recommend using the ALMOST FULL flag >> instead of the FULL flag. >> EMPTY does not have this problem. It goes active on the same read clock >> edge that is reading the last piece of data out of the FIFO. EMPTY >> then goes inactive again after a data entry has been written into the >> FIFO and the internal signal hes been re-synchronized to the read >> clock, which takes a few read clock cycles. This asymmetric behavior >> assures that the EMPTY flag is appropriately extremely fast in stopping >> any further erroneous reads, but is more "relaxed" in allowing the >> reading to restart again. Note that this read latency only occurs after >> the FIFO had gone empty. If anybody has questions about the Virtex-4 >> FIFO, I am the right person to ask. I have designed FIFOs, on and off, >> for over 35 years... Peter Alfke, Xilinx Applications > > So Peter, what do those of us with lowly Spartan-II FPGA's do if we want > say, a 16x9 FIFO? > -Dave A very small 16 by N sync FIFO is easy in the SpartanII using N SRL16E's (and a 5 bit counter) Peter WallaceArticle: 90622
here we go again...showing off stupidity....Article: 90623
Hi Robert,
you also need to write an BMM file.
Otherwise data2mem has no idea of the memory segmentation inside your FPGA.
like this:
// 3 Blocks of 256 Addresses by 32 Bits of Data
ADDRESS_SPACE aemb_rom RAMB4 INDEX_ADDRESSING [0x000:0x5ff]
BUS_BLOCK
XLXI_9/XLXI_1/BRAM/Mram_RAM_Modul_inst_ramb_1[31:16] LOC = R0C0
OUTPUT = ROM0_high.mem;
XLXI_9/XLXI_1/BRAM/Mram_RAM_Modul_inst_ramb_0[15:0] LOC = R1C0
OUTPUT = ROM0_low.mem;
END_BUS_BLOCK;
BUS_BLOCK
XLXI_9/XLXI_2/BRAM/Mram_RAM_Modul_inst_ramb_1[31:16] LOC = R4C0
OUTPUT = ROM1_high.mem;
XLXI_9/XLXI_2/BRAM/Mram_RAM_Modul_inst_ramb_0[15:0] LOC = R5C0
OUTPUT = ROM1_low.mem;
END_BUS_BLOCK;
BUS_BLOCK
XLXI_9/XLXI_3/BRAM/Mram_RAM_Modul_inst_ramb_1[31:16] LOC = R2C0
OUTPUT = ROM2_high.mem;
XLXI_9/XLXI_3/BRAM/Mram_RAM_Modul_inst_ramb_0[15:0] LOC = R3C0
OUTPUT = ROM2_low.mem;
END_BUS_BLOCK;
END_ADDRESS_BLOCK;
The LOC-infos come from the floorplaner UCF-output after PAR.
The Path is adapted from the blockname (replace the appropriate
underscores by slashes) and the bussegmentation, well, you simply got to
know and add in the file.
The OUTPUT Statement gives the filename for each segments file.
I spent a lot of time to find out about this because XILINX provides no
straightforward information about the BMM syntax.
Have a nice synthesis
Eilert
Robert schrieb:
> THIS IS IN CONTINUATION TO THE THREAD I MADE A COUPLE OF DAYS AGO. I
> WANTED TO ISOLATE THIS FROM THE OTHER STUFF, HENCE THE NEW THREAD:
> Refer here for the older thread:
> http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/ca8c05acec5703b3/a2502f9b088ecdea?lnk=raot&hl=en#a2502f9b088ecdea
>
> Hi,
>
> Here's what I need to do.
>
> 1) I will generate the data in a text file using Python scripts.
> 2) Will probably write another script or use Matlab to convert this to
> a .mem format which is readable by Xilinx.
> 3) Will use data2mem from command line to convert .mem file to either a
> .bit file or .v file. I will first try with verilog file, which I will
> then include into the project. The verilog file will contain the
> initialization for the RAM. Later on, I am planning to just use
> data2mem to generate .bit file, so that I can directly download it to
> the FPGA. (The different web-pages on Xilinx talk about .elf file, but
> as I don't have any code to write on the FPGA, but rather just some
> data, I don't know whether I should be concerned about this or not)
>
> Now, if I understand it correctly, these are the only steps required.
> Is it necessary to do something about the RAM in the hardware design?
> Like specifying where to store, the memory design etc?
>
> Update:
>
> Ok, I tried to do this. I defined a simple mem file like this:
>
> @0000 2A
> 3B
> 4C
> 5D
>
> I saved this as example.mem.
>
> Now, I tried data2mem -bd example.mem -o v outputverilog.v
>
> I was expecting a verilog file at the output. However, nothing happens.
> There is no error, but no output file either.
>
> Any help would be appreciated.
>
> Thanks,
> Robert.
>
Article: 90624Hi John, ...and I spent so much time with that nasty data2mem tool... :-( But it's good to hear that an alternative and more straightforward solution exists, even if it's limited to XILINX. The bad thing is that it can't be taught in VHDL courses unless it is supported by many (at least the important) tool vendors. Until then we have to deal with questions like that of Robert. I hope this feature finds it's way into VHDL 20xx and will be supported by more tool vendors much earlier. Thank you John for the information. (And to the XILINX programmers as well. It's the first positive feature of the 7.1 version up to now IMHO.) Eilert John McCluskey schrieb: > I read this thread about initializing FPGA memory with some interest. > Well over a year ago, I asked the XST developers in Grenoble to add > support for File I/O during VHDL elaboration. This actually works in ISE > 7.1! You can write a VHDL function that opens a file (using the TextIO > package), reads data out of it, and returns an array that can be used to > initialize a signal array that has memory inferred on it. -- snip -- sorry, needed to cut to old post
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